> describes steps for a release review as something that
happens during
> the run up to ballot.
I can see that
https://github.com/jakartaee/specification-committee/issues/39
has not
been touched yet
Right, it was brought up as an action item for the EF to
look into why they have diverged. It does not apply to EE9
as every spec requires a release review.
> The interaction with the PMC and EMO have been
described as asynchronous
> by Wayne Beaton in the past. If those are requirements
for ballot
> completion, that needs to be made part of the process.
Correct me if I'm wrong but as I understand it:
Ballot - an approval from the Jakarta EE WG for the
release/a process
defined by the spec committee
Release review - an approval from Eclipse Foundation for the
release/a
process defined by Eclipse Foundation
* both can run in parallel; EF/EMO will wait for ballot to
conclude and
approve the release if and only if ballot passes
* each checks different things (ie IP log, vendors'
expectations,...)
* one needs to get both approvals in order to publish the
release
Yes, that is how it is described in the
https://www.eclipse.org/projects/efsp/,
but the checklist has no join point for this trio of
approvals: "
A
Release Review concludes successfully with approval from
the PMC and EMO, and approval by a Super-majority of the
Specification Committee."
So really, the current 'on ballot completion, the
specification committee mentor...' checklist needs to
include waiting for approval from the EMO and PMC before
creating the project checklist item that include the release
of the APIs. Likewise, the promotion of the TCK and merge of
the specification page should not be done by the mentor
before this approval.
I'll raise this on this week's spec committee call and
see what needs to be done about BV.