Re: [jakarta.ee-spec.committee] The process to create the first set of F

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

Wayne Beaton wrote on 4/22/19 12:42 PM:

 

I forget, do we have criteria somewhere for what we'd like to see for a Progress Review?

The EMO's minimum criteria for a review is a coherent executive summary and clean IP check. It's up to the PMC and specification committee to determine what more they need to see in order to cast a positive vote.

Sounds like this is something we should discuss soon.

 

Since most of the specifications share a TCK, these reviews will likely be done in larger batches, with the TCK release version finalized for all specifications before we engage in the process for the first batch (or we can wait and batch them all together, which probably makes more sense).

They don't share a TCK.  They share a TCK source code repository.  Most of the TCKs are independent.

Does this fact change anything about my assertion?

We need to figure out exactly how we're doing the staging for all the things that need to be approved and finalized to complete a specification release.

Finalizing the TCK before approving the spec runs the risk that the spec is not approved and the TCK will need to be changed, or that someone will claim conformance to a TCK before the spec is approved.

Many such events are "unlikely", so we can just proceed on the assumption that they'll never happen and then do something exceptional if they do.  Or we can design the process to make such events impossible, but I'm not sure if that's possible.  Maybe we need to require that all the reviews and approvals happen at the same time, with some central coordination to ensure the correct result at the end?

I'm hoping someone will propose exactly how to stage all these approvals and releases so as to reduce or eliminate the possibility of these unlikely events.

 

Which parts of the JESP are rules for which there can be no exceptions, and which parts are guidelines for which there can be exceptions?

The IP Policy, terms of licenses, and fundamental principles of the process must be preserved. As a general rule, it is IMHO reasonable to consider an exception for anything that is "process for the sake of process". The more that I think about it, I'm inclined to also ask the specification committee to approve the exception.

How would we know that that's the case?  Is it written somewhere in the process itself, or some other Eclipse document, which things can and can not be changed as exceptions?  Are there "general rules" or "fundamental principles" written down somewhere?

Lacking that, I assume everything in the process is required and can't be changed unless the process itself says it can be changed.