To engage in a release review, each
specification project team must:
- Create a Release record in the PMI (the
Release record should include the release
name, date, and a sentence that describes
the intention behind the release);
- Submit their IP Log for review;
- Request PMC approval of the Release and
corresponding release documentation (PMC
approval request is an email to the PMC
mailing list, a single +1 from any member
of the PMC indicates approval); and
- Create a PR against the "specifications"
repository that completely describes the
contents of the Specification Version that
they're releasing.
According the process, the project team
must also notify the EMO. In practice the
EMO monitors the IP Log submission and the
PMC approval request and initiates the
review process based on that.
The Specification Committee Chair (or
their designate) will initiate the ballot (I
am currently the designate for the interim
Chair). The timing and actual trigger of the
start of the ballot was a topic of
discussion today's call.
All of the above definitely applies to
Specification Projects that have not already
engaged in a release review. This includes
Jakarta EE Platform, Jakarta CDI, Jakarta Bean
Validation, Jakarta Batch, and Jakarta Server
Faces.
While not a specification project, the
Eclipse Jakarta EE TCK will have to engage in
a Release Review (since it's not a
Specification Project, no Specification
Committee ballot is required, so skip step
4).
Since most of our Specification Projects
have already successfully engaged in a Release
Review, the Specification Committee may choose
to designate the Jakarta EE 8 follow up as a
Service Release. Per the EFSP, a
"Specification Team may consult with their PMC
and Specification Committee to determine
precisely what constitutes a minor change
and/or clarification."
Something that I hadn't thought of on the call
is whether or not the addition of a
Specification Document may be considered as
minor and/or a clarification.
For example, the Jakarta Servlet project
engaged in a release last year (it had a
different name, but it was the same project).
The Jakarta EE 8 release will contain no new
functionality over and above what was included
in that release, but will include a
Specification Document that it did not
previously have. I have some thoughts about
how we can argue that the addition of a
Specification Document that is based on
Javadoc that was included in the previous
release can be reasonably thought to be a
clarification.
If the Specification Committee determines
that the upcoming release is a Service
Release, we can skip steps 2 and 3.
In practical terms, submitting an IP Log
and requesting PMC approval should take about
two minutes for a committer. Processing the IP
Logs requires a pretty significant investment
from me, and all of those requests for PMC
approval will require that the PMC respond to
them all (so it's far more work for me and the
PMC than it is for the project team).
I'm a big fan of not processing 30+ IP
Logs.
HTH,
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.