| Re: [ee4j-pmc] Jakarta EE 9 Release reviews |
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...
Jakarta Mail is not in that same boat. If Lukas submitted an IP log, then that was a mistake or just over excited. :-)
> 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" (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- 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
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
Join us at our virtual event: EclipseCon 2020 - October 20-22