If you don't want to call these "reviews", then we're going to need
a new word for what it is that we're doing that's independent of a
Release Review. I don't think distinguishing between "Review" and
"review" is going to help us here. If we have to update the EFSP to
define what we're doing as a Specification Review, then let's do
that.
Wayne Beaton wrote on 8/7/19 8:21 PM:
I suspect that our overloading of the word "review"
is what's confusing. I'm using the word Review in the
sense that it is defined in the EFSP/EDP (I've been trying to
consistently use pseudo-legal capitalization when I mean one of
the defined terms).
We're doing specification reviews in the sense that we're
reviewing specifications in the lead up to a Release (and--at
least in some cases--corresponding Release Review).
What I mean is that there's no formal notion of a
"Specification Review", or any formal notion of any
specification-level review, in the JESP/EFSP . There is a
formal notion of Release Reviews are for
Specification Projects.
Wayne
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.
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
|
