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

Santiago,
The checklists are in place because we as humans can't remember everything that is required to successfully release a Specification Version.  In order to release a new Spec, you also need the corresponding API, TCK, and CI.  Ensuring that all of these pieces are properly created, reviewed, approved, and balloted can be time consuming and error prone.  Since we multiple organizations involved in this process now, we need reminders of what needs to be done and when.  That's where the checklists come into play.

FYI, the overall Spec Operations Guide is here:  https://jakarta.ee/committees/specification/operations/

The codified version of this ops guide is basically the checklists.

The official ballots for the Specification Versions does need to be recorded explicitly for the members of the Spec Committee.  This is the "sign off" for the IP flow.  This is being done via the public Spec distribution list because it needs to be public and recorded.  Currently, we have no other means for a formal ballot process.

---------------------------------------------------
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:        Santiago Pericas-Geertsen <santiago.pericasgeertsen@xxxxxxxxxx>
To:        EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Date:        10/26/2020 13:56
Subject:        [EXTERNAL] Re: [ee4j-pmc] Jakarta REST 3.0 Review
Sent by:        ee4j-pmc-bounces@xxxxxxxxxxx




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.
https://projects.eclipse.org/projects/ee4j.jaxrs/reviews/3.0.0-release-review

 


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://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




Back to the top