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