|
On 2018-05-23 5:12 PM, Bill Shannon
wrote:
Mike Milinkovich wrote on 05/22/18 10:15 PM:
On 2018-05-22 11:21 PM, Bill
Shannon wrote:
Will those
rules thus be decided by EF and consistent across
all TCKs from all projects?
Well that's actually a tough question. The JCP
allowed Spec Leads to license TCKs as they saw fit.
Red Hat uses the ALv2 for its TCKs for example. So
this definitely has to be discussed. But I am
searching for solutions which are consistent. The JCP
Spec Lead approach is *not* going to work at the
Eclipse Foundation because there is no Spec Lead which
acquires special IP rights. So what worked before will
not necessarily work here.
The EFTLA could simply require that you "pass" the TCK,
where each TCK could define what it means to "pass". The
TCK rules would only apply when using the EFTLA, not when
using the TCK under its open source license. Would that
give too much freedom to TCK authors and too little
consistency across TCKs? Or would consistency be enforced
by the PMC?
I think that if there are TCK consistency requirements
they enforced by the Spec Committee, not the PMC.
(I guess at this point I'm thinking of the Spec Committee as
more like the JCP PMO - defining the rules that we'll operate
under. You're suggesting that it will also operate more like
the JCP EC - approving all the specs.
Yes, that was always my viewpoint. There has to be some body
that adopts the specifications, and that body needs to be in the
Jakarta EE Working Group, not in the PMC.
Should it not be the Working Group itself? Is the Working Group
not playing an analogous role to the JCP EC? Or do you believe
the Working Group has delegated this responsibility to the Spec
Committee? (I probably don't understand the formal relationship
between the Working Group and the Spec Committee.)
I don't understand the source of confusion. In my mind this is laid
out clearly in the Jakarta
EE Working Group Charter via the "powers and duties" section
of each of the committees. Can you please take a look and let us
know if we need to revise this governance document?
Anyway,
would you expect the Spec Committee to define the TCK
consistency requirements, or just to enforce the
requirements defined by some other group?
Both. The Spec Committee's purview includes laying down all
requirements for the Spec Process, including any TCK consistency
requirements. I am not thinking of active enforcement, but the
Spec Committee could simply decline to adopt a Specification
whose TCK was inadequate, just as we would expect them to do if
the Specification Document was not sufficiently detailed to
enable independent implementations.
If
the spec process is reusable by other Eclipse projects, should
the TCK requirements be defined in some Jakarta EE specific
group, instead of in the group that defines the spec process
for all of Eclipse?
The Spec Process is not reusable by other Eclipse projects
directly. The Spec Process is reusable by other working
groups. Spec processes are not an inherently open source
thing. They require additional agreements (like the
Participation Agreement for example) which add extra IP flows
not used by open source projects.
I thought we had agreed that the process we're defining would be
independent of any Jakarta EE specific requirements, precisely so
that it could be reused elsewhere in Eclipse. I understand that reuse
is not the same as use, so some things that you mention
above might change from use to use.
But then it's weird if the group defining the process is also the
group that approves Jakarta EE specific uses of the process.
Maybe you're expecting to split the responsibilities and fork the
group if/when the process is used elsewhere in Eclipse?
Yes, exactly. I realize that this flow isn't optimal, but Jakarta EE
is the group with the core requirements and the tightest timelines.
The other groups will be pulled in later, and if they can come up
with use cases that require an update to the over-arching process
document, we will deal with it as an update.
This is why the first two definitions in the spec requirements
doc are:
A “Working Group” is an Eclipse Foundation Working
Group established under the Working Group Process. Definitions
from the Working Group Process are included herein by
reference.
A “Specification Committee” is a committee of a Working Group
established to manage this Process for technologies within the
Scope of its Working Group.
Basically, the Spec Committee could say "this TCK is not
good enough" and refuse to adopt a new Version of a Spec.
"Not good enough" is different than "not consistent with other
TCKs". And of course you want to set expectations in this
area before the TCK is started, not after it thinks it's
complete.
I think that it would be possible to state a set of requirements
for TCKs that establishes a level of consistency that applies to
all. As a high level, I think it is clear that a TCK must be of
sufficient quality to demonstrate that an independent implementation
is compatible with the Specification.
I agree, and those rules would be Jakarta EE specific, right?
Sure. I think that each Spec Committee will refine these types of
requirements for their specific domain.
|
