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