Re: [jakarta.ee-spec.committee] Presentation of Ballots for Release Revi

["Kevin Sutter" <sutter@xxxxxxxxxx>]

We're getting bogged
down with process...  IMHO, the Eclipse Release Reviews are just a
formality.  Let's focus on our pre-reviews and ballots for the Specification
and Apidocs PRs.  Once we get those rolling on a regular basis, then
we can worry about doing the Eclipse Release Reviews.

---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Jakarta EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:
       Bill
Shannon <bill.shannon@xxxxxxxxxx>
To:
       Wayne
Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
Cc:
       Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:
       08/07/2019
10:38 PM
Subject:
       [EXTERNAL]
Re: [jakarta.ee-spec.committee] Presentation of Ballots for Release Reviews
Sent
by:        jakarta.ee-spec.committee-bounces@xxxxxxxxxxx

---

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

On Wed, Aug 7, 2019 at 11:06 PM Bill
Shannon <bill.shannon@xxxxxxxxxx>
wrote:
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 


On Wed, Aug 7, 2019 at 6:18 PM Bill Shannon
<bill.shannon@xxxxxxxxxx>
wrote:
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

On Wed, Aug 7, 2019 at 4:26 PM Bill Shannon
<bill.shannon@xxxxxxxxxx>
wrote:
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 Specificationmust 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:

https://github.com/jakartaee/specifications/pull/63
https://github.com/jakartaee/specifications/pull/64

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.

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee