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