Skip to main content

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

The EDP and EFSP/JESP require no ceremony, no IP Log, no review for milestone builds (the EDP avoids referring to the distribution of milestone builds as "releases").

https://www.eclipse.org/projects/efsp/#efsp-milestones

Wayne


On Thu, Jun 4, 2020 at 9:06 PM Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
Circling back to the initial note from Wayne and Kevin's response --

The template for the PRs that are being created in anticipation of the
Jakarta EE 9 Milestone release includes links for the Release Review and
IP Logs.

Just wanted to get confirmation that it is not a requirement to point
these anywhere for the Milestone release.  Wayne, and/or Kevin, is this
correct?

And possibly, to avoid potential reader confusion, we might consider
removing the empty links just so that readers don't think there is some
problem or omission. (This maybe a judgement call, I'm not sure.)

Thanks,

-- Ed

On 6/4/2020 2:33 PM, Lukas Jungmann wrote:
> 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
>>
> _______________________________________________
> 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


Back to the top