I'll leave the timing up to you. If they're only a few days apart,
that's probably fine, as long as the final approval waits for all
the required reviews.
In any event, we won't need to modify the EFSP/JESP to accommodate
this.
Wayne Beaton wrote on 8/7/19 3:06 PM:
We could, but why?
Assuming that we get CDI ready for review in the next few
days, there's nothing to be gained by engaging in two separate
release reviews for the same project.
Wayne
Actually, a Release Review for a
project doesn't need to include all of the content of the
project. Couldn't we just do a Release Review of the CDI
project that includes only the DI component, then do another
Release Review of the CDI project later that includes the
CDI component?
Kevin
Sutter wrote on 8/7/19 1:37 PM:
Wayne,
Since
we are allowing multiple repos per Specification
Project, this voting of individual repo specifications
may become more common. I think your proposed
workaround is fine for now. But, we should log the need
to modify the EFSP/JESP to allow for multiple
specification releases within a single Specification
Project. Thanks!
---------------------------------------------------
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:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>,
Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
Date:
08/07/2019
03:29 PM
Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Presentation of Ballots
for Release Reviews
Sent
by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
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!
_______________________________________________
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
_______________________________________________
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
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
--
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
|
