[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ee4j-pmc] Jakarta EE 9 Release reviews
|
On 6/4/20 10:35 PM, Kevin Sutter wrote:
Thanks for the reminder note, Wayne. I think we're running with the
processes as you have defined, but it never hurts to get reminded. Thanks.
A couple of specific comments...
I have received some IP Logs for, I think, two specification projects
(Jakarta Activation and Jakarta Mail), so I've assumed that the project
team believes that these are good to go and will start the release
process, including a ballot, unless I'm instructed otherwise. As part of
the process of engaging in a release, the project team needs to seek
your approval; that is your opportunity to decide if the release makes
any sense.
I believe Lukas is going to go ahead with the Jakarta Activation GA
release. Bill had pretty much finished that up for the 2.0 release and
now Lukas is picking it up. We've had an ongoing discussion via the
Specifications PRs. I've explained that it's fine to move forward with
this activity, but do not expect that to be completed before the Jakarta
EE 9 Milestone release. If we move forward with the final release
review for Activation 2.0, we should get more Spec Committee eyes on it
than just mine...
I'd like to finish Jakarta Activation rather sooner than later since
everything except of "paper work" is ready since April; PMC approval is
being requested through
https://www.eclipse.org/lists/ee4j-pmc/msg02674.html (... Kevin - I
believe the release date has been fixed already)
Jakarta Mail is not in that same boat. If Lukas submitted an IP log,
then that was a mistake or just over excited. :-)
correct, the project is not ready for the prime time yet and IP log was
submitted "by accident" in this case.
thanks,
--lukas
I defer to your judgement (and that of the specification committee)
regarding the timing of the reviews. I can deal with them as they
arrive, or I can batch them according to your instructions ("just batch
them into groups of X-ish" is sufficient direction).
Maybe we could batch them up once a week? And, then maybe increase that
as we get closer to GA. The idea is to get these final reviews done
incrementally instead of all at once like we did with Jakarta EE 8.
But, given our track record, I don't know if we'll get these PRs
incrementally or not...
I've also noted that several projects have created multiple release records.
I actually like this approach. It's very clear on the expected release
content, especially when there are different versions of the associated
release records. This is also consistent with what we have done with
MicroProfile and it's multiple release records.
Many projects have not yet created release records for their Jakarta EE
9 releases.
Really? I thought we had those covered. If there are missing records,
can you let me know which ones? I'd like to follow up. Thanks.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
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: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Date: 06/04/2020 14:51
Subject: [EXTERNAL] [ee4j-pmc] Jakarta EE 9 Release reviews
Sent by: ee4j-pmc-bounces@xxxxxxxxxxx
------------------------------------------------------------------------
Greetings EE4J PMC.
I've noticed that a handful of projects have created release review
records related to Jakarta EE 9. In anticipation of this release, I've
created a "_simultaneous release_
<https://projects.eclipse.org/releases/jakarta-ee-9>" (master) record to
group all of these releases together (this grouping helps me run
statistics and things).
I understand that most of these records were created some time ago in
anticipation of this release. The date on them is June 30, which I
believe is mostly bogus and I expect that project teams will adjust
these dates given some direction (there's no urgency from the EMO's
perspective other than that the bogus dates might be confusing to adopters).
By way of reminder, milestone builds require no ceremony (there is no
review requirement for milestone builds). Project teams are encouraged
to make and disseminate frequent milestone builds to solicit feedback.
Recall that milestone builds are intended for implementers to use to
work on their products and must not be used as a basis for declaring a
project as a compatible implementation.
I have received some IP Logs for, I think, two specification projects
(Jakarta Activation and Jakarta Mail), so I've assumed that the project
team believes that these are good to go and will start the release
process, including a ballot, unless I'm instructed otherwise. As part of
the process of engaging in a release, the project team needs to seek
your approval; that is your opportunity to decide if the release makes
any sense.
Note that there is no rule that states that these projects all have to
actually release on the same day, just that they must all work together
as a coherent whole when the corresponding profiles are released.
I defer to your judgement (and that of the specification committee)
regarding the timing of the reviews. I can deal with them as they
arrive, or I can batch them according to your instructions ("just batch
them into groups of X-ish" is sufficient direction).
I've also noted that several projects have created multiple release
records. Specifically, specification projects that own multiple
specifications seem to have created a release record for each separate
specification. This is not required according to the process. Release
reviews are run on at the project level, so a single release record is
sufficient (especially if all specifications are being released at the
same time). If, however, you prefer to have separate release records for
each specification, the EMO can run with that. I defer to your judgement
(it's only a little bit more work to have separate release records).
Many projects have not yet created release records for their Jakarta EE
9 releases. AFAIK, the actual release is still at least a couple of
months away, so there's no immediate requirement to have this
information entered into the system (sooner is better than later). As I
notice these records being created, I'll add them to the master record.
Note that the EMO has changed its process a bit and will start creating
Bugzilla records to track the specification committee ballots. These
tracking bugs are intended primarily to help the EMO track the ballots
that are in progress. I don't believe that they are meaningful for
anybody else. You are, of course, welcome to monitor these tracking
issues, but there is no requirement for you (or anybody outside of the
EMO) to engage on them at this point. We will continue to run ballots in
the mailing list.
This note ended up being longer than I had anticipated. I hope that it
makes sense. Let me know if anything requires clarification.
I intend to send this to the specification committee as well.
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
/Join us at our virtual event: //_EclipseCon 2020_/
<https://www.eclipsecon.org/2020>/- October
20-22/_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ee4j-pmc
