Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-pmc] Jakarta REST 3.0 Review
Kevin,

In the past, individual Java EE Specifications were not released separate from the Platform.  (There may have been a couple of exceptions along the way, but for the most part, the Platform content drove the individual Specifications.)  With the EFSP (and JESP), we are allowed to create and deliver new or updated Specifications in between the Platform Specs.  Or, maybe even totally separate from the Platform Specifications.  Once we get this Jakarta EE 9 foundation release in place, the ability to define individual Specifications opens up considerably.  Jakarta MVC and NoSQL are already attempting to blaze this path.

 This is precisely my concern. Given that we want to have a more agile evolution of the specs going forward, the release process needs to be simplified to encourage such a practice. Jakarta REST has a 3.1 release almost ready and just thinking about going through all these steps again, well, let’s just say I’m not looking forward to it. 


I do agree we have quite a bit of process.  We are always open to new ideas that might streamline this process and still provide us the protections required for a Specification process.  Thanks for speaking up.

 It’s hard to make meaningful suggestions without a complete understanding of why certain steps are needed. But generally speaking, the release process involves PR’s with checklists, bugs, e-mails, release records, etc. there doesn’t seem to be a central place where progress can be easily assessed (hence, perhaps, the reason why this e-mail thread started). Also, does voting really need to happen over e-mail? We already have issues and PR’s. Is it at all possible for the PMC to interact with the EMO on behalf of the Jakarta projects? Anything we can do to streamline the process would help.

 Thanks.

— Santiago

---------------------------------------------------
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:        "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To:        EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Date:        10/26/2020 11:38
Subject:        [EXTERNAL] Re: [ee4j-pmc] Jakarta REST 3.0 Review
Sent by:        ee4j-pmc-bounces@xxxxxxxxxxx


Hi Santiago,

 

I agree that is complex for specification projects. A lot of this is down to the fact that a specification project is special. The specification process release review is defined here https://www.eclipse.org/projects/efsp/?version=1.2#efsp-reviews-releaseand the various checklists are maintained by the specification committee here https://github.com/jakartaee/specification-committee

 

The specification process defines that the EMO, PMC and a ballot of the specification committee all have to be successful for a spec to be released. I assume the PMC and EMO approvals are inherited from the standard Eclipse release reviews that all projects have to undergo.

 

What the spec committee need to do (if they haven’t already) is a set of simple steps which detail what is needed to meet the needs of the EFSP release review and in what order so it doesn’t feel like a black art. 

 

Steve

 

 

From:ee4j-pmc-bounces@xxxxxxxxxxx <ee4j-pmc-bounces@xxxxxxxxxxx> On Behalf Of Santiago Pericas-Geertsen
Sent: 26 October 2020 14:12
To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Subject: Re: [ee4j-pmc] Jakarta REST 3.0 Review

 

Hi Ivar,

 

 The whole release process seems very convoluted, especially for those that aren’t in the day-to-day discussions related to it. There’s multiple PR’s with long checklists, multiple e-mails, reviews, etc. By contrasts, a release in the JCP days was a lot simpler. 

 

 I fear this process will discourage projects from releasing often (I certainly feel that way), and just prevent Jakarta EE to evolve at the “desired” pace. I hope we can figure out a simpler process going forward. I don’t pretend to have a holistic view of the process to provide any actual recommendation, but my point of view, it looks unnecessary complicated.

 

 Thanks.

 

— Santiago

 

 

On Oct 24, 2020, at 9:38 AM, Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx> wrote:

 

No questions are dumb! ;)
I must say that I am a little unsure which review period you are referring to that has ended...

 

The Ballot will conclude on November 3rd. 
The proposed release date is set by the project team to October 30 in the release record. This is the date that probably should be adjusted by the project team. If it feels better, go ahead and do so.
This is the date the EMO will conclude its release review, but since it depends on the ballot, that won't happen until November 3rd.

 

There are so many moving parts here that I am sure there are some small inconsistencies and chicken-and-egg situations here and there. We just need to be a little pragmatic when it comes to some of the less important details.

 

Ivar

 

 

On Sat, Oct 24, 2020 at 2:55 PM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
Thank you for this information, Ivar.
Maybe this is a dumb question, but what sense does it make to end the review period earlier than the ballot period…?
-Markus
 
Von:ee4j-pmc-bounces@xxxxxxxxxxx[mailto:ee4j-pmc-bounces@xxxxxxxxxxx] Im Auftrag von Ivar Grimstad
Gesendet: Samstag, 24. Oktober 2020 09:35
An: EE4J PMC Discussions
Betreff: Re: [ee4j-pmc] Jakarta REST 3.0 Review

 

 

The Ballot for release review by the Specification Committee will conclude on November 3, 2020. See this thread for progress: https://www.eclipse.org/lists/jakarta.ee-spec/msg01136.html

 

As you can see from the release record by the EMO, the status is pending, since it depends on the review mentioned above.

 

Ivar

 

On Sat, Oct 24, 2020 at 9:24 AM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
The review of Jakarta REST 3.0 is over since three days. What was the result of the review?
-Markus
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ee4j-pmc

 

--
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation, Inc.
Community. Code. Collaboration. 
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

 

--
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation, Inc.
Community. Code. Collaboration. 
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


_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/ee4j-pmc__;!!GqivPVa7Brio!I1P_TTMXzBFCdY4zgPwoTpD1auw-bU2U0cH6D7-bDbGrNPp8H6hr5QwxeSKSb5lRoMagm_57GA$

Back to the top