Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ee4j-pmc] Jakarta EE 9 Release reviews

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


Back to the top