Re: [jakarta.ee-spec.committee] Recent Edits

[Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>]

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. The Eclipse Management Organization (EMO) will be responsible for staffing the implementation and execution of the spec process.

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.

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.

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.

--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
(m) +1.613.220.3223