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

Certainly my view is a bit too naive or simplified, but here in my office I can just trigger virtually any process by a "single" click thanks to automation tools like Jenkins.

The EF has its own infra structure and is frequently asking to use that instead of public or third party infra.

Fair enough. So EF, please set up an infra that allows committers to just click a single button to send everything needed to the correct places, the set correct deadlines, and so on.

And provide a UI for everybody in charge to simply click "Approved" just GitHub does with PRs. Or just use Github Actions and PRs for your reviews directly.

As all spec projects are managed by the EF (not by the commiters) on GitHub, it should be possible to do this in a rather generic way.

As I said, maybe too naive, but that should be the vision if we want "Publish Early, Publish Often", and if we want non-fulltime-checklist-experts being the only one able to run a release of a spec project. If that is impossible, I do not see the benefit of the using the EF infra.

-Markus

 

Von: ee4j-pmc-bounces@xxxxxxxxxxx [mailto:ee4j-pmc-bounces@xxxxxxxxxxx] Im Auftrag von Steve Millidge (Payara)
Gesendet: Montag, 26. Oktober 2020 20:31
An: EE4J PMC Discussions
Betreff: Re: [ee4j-pmc] Jakarta REST 3.0 Review

 

I don’t know if this is a sensible suggestion but as far as I can see some of the checklist items are about making the https://jakarta.ee/specifications/ website work correctly rather than substantive requirements of the EFSP.

 

Perhaps for future releases these steps could be split from what is required to formally bring a specification to ballot and could follow and possibly be automated as part of the actual physical act of releasing the artefacts. I know it is often these requirements that are the most fiddly and least understood as to “why”. I know they confuse me as they have to have links to things that don’t exist etc.

 

Steve

 

From: ee4j-pmc-bounces@xxxxxxxxxxx <ee4j-pmc-bounces@xxxxxxxxxxx> On Behalf Of Kevin Sutter
Sent: 26 October 2020 19:19
To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Subject: 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