Um, I think that's all fine, but you didn't really answer whether
we're doing a "specification review" or not. Earlier you said:
There's no notion of a "specification
review".
What are these things we're doing with specifications that involve
voting if not "specification reviews"?
Wayne Beaton wrote on 8/7/19 7:22 PM:
What we decided was that the Specification Projects
that have not yet engaged in a Release Review needed to engage
in one. Specifically, Jakarta Batch, Jakarta Bean Validation,
Jakarta CDI, and Jakarta EE Platform all need to engage in a
full Release Review. All those Specification Projects that have
previously engaged in a Release Review only need Super-majority
approval of the Specification Committee for their Service
Release (no new features).
The Jakarta Managed Beans (which is owned by Jakarta EE
Platform) and Jakarta Dependency Injection (which is owned
by Jakarta CDI) Specifications are are currently listed as
being in the first wave, split from the other Specifications
owned by their Specification Project (in both cases, the
project needs to engage in a Release Review). This split
makes doing a ballot/review at the Specification Project
level a little weird, but--as I said earlier--I believe that
doing per-Specification ballots is probably easier for folks
to understand.
I don't believe that any change to the process is required
to split a ballot. The process (JESP/EFSP) requires
Super-majority approval; it doesn't specify how the ballot
is undertaken. A Project can have releases that include
only part of their code base (I tend to find this weird,
but it seems to work for some projects); I'd like to avoid
splitting anything here, mostly because the releases are
all going to be on the same date.
I recommend that we optimistically schedule the Release
Review for Jakarta CDI to conclude on August 28/2019 and
start the ballot for Jakarta DI immediately. We'll monitor
progress on the Jakarta CDI Specification and adjust the
date as necessary. We'll wait until we have both
Specification Ballots in progress before we ask the PMC for
their approval. Note that we'll also need an IP Log review
for the Jakarta CDI Specification Project, which--assuming
that there are no additional third-party dependencies
forthcoming--we can start at any time (click here).
I took a quick look through the first few of the wave 1
specifications and they seem ready to me. We can show
progress by starting ballots for Jakarta Annotations and
Jakarta Concurrency at our earliest convenience.
Wayne
Ok, maybe I'm confused, but I've been
thinking of these as two reviews that happen in parallel.
And in many cases we decided we don't need a Release Review
at all since the projects have recently done a Release
Review, so if that's not a "specification review" with a two
week ballot, what is it?
I definitely think there should be a separate ballot for
each specification.
Wayne
Beaton wrote on 8/7/19 2:34 PM:
There's a
mutual dependency here, right? The specification
review can't be declared successful until the
release review is complete, right?
Sort of. There's no notion of a "specification
review".
I'm probably splitting hairs, but... a
Specification is declared a Final Specification
after the successful completion of a Release
Review. In order to successfully complete a
Release Review, Super-majority approval of the
Specification Committee is required.
It's not really a mutual dependency. The
Specification Committee's approval is one of the
requirements that feeds into the Release Review.
But I don't think that it hurts to think of it as
a mutual dependency.
I had expected to run a single ballot for each
Specification Project. Running a ballot for each
Specification isn't wrong, it's just going to
require a small number of extra ballots.
HTH,
Wayne
Wayne
Wayne Beaton wrote on 8/7/19
12:59 PM:
Greetings Jakarta EE Specification
Committee,
This is not the call for the ballot.
Rather, this is a proposal for how the
ballot will be presented.
The JESP/EFSP requires a ballot on the
release of each Specification Project.
Jakarta Dependency Injection is one of two
specifications "owned" by the Jakarta Contents
and Dependency Injection Specification
Project.
I propose, that rather than wait for CDI,
we push forward on this specification
individually, with an understanding that the
ballot for both this specification and for the
CDI Specification must be completed
successfully before the release review for the
CDI Specification Project can be
declared successful (i.e. one release review
for the project, and one ballot for each
specification). I think that this will be less
confusing for the community.
There's a mutual dependency here, right? The
specification review can't be declared successful
until the release review is complete, right?
Regarding the content of the ballot
request, I propose that the call for the
ballot include links to the related PRs which
contain all of the relevant information. The
ballot request will look something like this:
I need your vote to approve the Jakarta
Dependency Injection 1.0 release.
The relevant materials are available
here:
Per the process, this will be a fourteen
day ballot, ending on August 22/2019. I
require a Super-majority positive vote of
the Specification Committee members.
Community input is welcome, but only votes
cast by Specification Committee
Representatives will be counted.
The Specification Committee is composed
of representatives of the Jakarta EE Working
Group Member Companies (Fujitsu, IBM,
Oracle, Payara, Red Hat, Tomitribe), along
with individuals who represent the EE4J PMC,
Participant Members, and Committer Members.
Do we have a public web site listing committee
membership yet? If so, you could just point to it.
Specification Committee representatives,
your vote is hereby requested. Please
respond with +1 (positive), 0 (abstain), or
-1 (reject). Any feedback that you can
provide to support your vote will be
appreciated.
Do we need anything else included in the ballot
call?
I'll send this out to the public list
tomorrow. Let me know ASAP if you have any
concerns.
Looks good to me, thanks!
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
|
