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.)
The
Eclipse Management Organization (EMO) will be responsible for
staffing the implementation and execution of the spec process.
I assumed Eclipse was also responsible for its definition. If not,
someone else should be leading the Spec Committee.
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?
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?
At some point we should talk about whether we want there to be any
"compatibility rules" as in the current TCKs, and if so what we want
them to be and whether they would be required to be consistent
across all Jakarta EE TCKs.
But out of curiousity, what is the status quo? Did someone
from Oracle or the JCP staff review the TCKs done by Red Hat
for its specs to decide whether they met some quality
objectives?
No, that was the job of the EC.
Then it sounds like basically what I am proposing here is the
status quo.
In that regard, yes.
|
