Ok, you're right. I'm getting confused by the project/repo
disconnect.
A spec project really should have one review for all the contained
specs. If we want to allow for multiple reviews, we probably do
need to update the EFSP, although I would probably argue for not
adding that additional complexity to the process.
If we really expect the CDI spec to be ready for review in a few
days, why don't we just hold the DI spec until then? I know we
actually wanted to start the ballot on something just so we could
show progress, but it doesn't seem like a few days would matter.
Kevin Sutter wrote on 8/7/19 3:23 PM:
The way I
read your
note and the EFSP/JESP is that our process requires a single
ballot for
the Specification Project. But, now we're going to allow for
multiple
ballots per Specification Project (one for each github repo).
That
sounds like a minor change that should be documented.
I'm not
asking
for multiple Release Reviews. Leave that as one for the
Specification
Project.
---------------------------------------------------
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:
Wayne
Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
To:
Jakarta
specification committee
<jakarta.ee-spec.committee@xxxxxxxxxxx>
Cc:
Kevin
Sutter <sutter@xxxxxxxxxx>
Date:
08/07/2019
05:07 PM
Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Presentation of Ballots for
Release Reviews
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
On Wed, Aug 7, 2019 at 5:38 PM Bill
Shannon
<bill.shannon@xxxxxxxxxx>
wrote:
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
|
