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.
|