Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] Jakarta EE Spec Committee Approved Meeting Minutes - September 30th, 2020

Just to chime in RE: using weekly builds.

 

I think this is one of the most difficult areas of the spec process given the chicken and egg nature of a Compatible Implementation being required to ballot a specification.

 

For future releases we need to resolve this as we are essentially trying to pin down for ballot what is a moving target wrt to the Compatible Implementation. My personal off the top of my head view is that using a nightly or weekly build should be allowed with the understanding that the CI can be updated after ballot to the final CI release. IMHO as long as you have a permanent api jar, spec document and a permanent set of TCK results from some CI then the ballot should be allowed. I don’t see the need for the exact version of the CI to be permanent and rebuildable.  After all the purpose of the CI is just to prove the specification and TCK can be implemented and tested.

 

Steve

 

From: jakarta.ee-spec-bounces@xxxxxxxxxxx <jakarta.ee-spec-bounces@xxxxxxxxxxx> On Behalf Of Tom Jenkinson
Sent: 15 October 2020 14:30
To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec] Jakarta EE Spec Committee Approved Meeting Minutes - September 30th, 2020

 

Thanks for the responses,

Tom

 

On Thu, 15 Oct 2020 at 14:00, Kevin Sutter <sutter@xxxxxxxxxx> wrote:

You're good, Tom.  Although the use of a weekly GF build is not ideal since it's not a permanent, re-buildable artifact, we decided to let this proceed.  It's not a recommended practice and we'll tighten this loophole in future releases.  But, for now, we are allowing it.  Thanks for asking!

---------------------------------------------------
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:        Tom Jenkinson <tom.jenkinson@xxxxxxxxxx>
To:        Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Date:        10/15/2020 04:24
Subject:        [EXTERNAL] Re: [jakarta.ee-spec] Jakarta EE Spec Committee Approved Meeting Minutes - September 30th, 2020
Sent by:        jakarta.ee-spec-bounces@xxxxxxxxxxx






On Tue, 13 Oct 2020 at 18:41, Paul Buck <paul.buck@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Jakarta EE Spec Committee - September 30th, 2020

Attendees (present in bold):

 

Kenji Kazumura - Fujitsu

Dan Bandera - IBM - Kevin Sutter

Ed Bratt - Oracle - Dmitry Kornilov 

Andrew Pielage - Payara - Matt Gill

Scott Stark - Red Hat - Mark Little, Scott Marlow

David Blevins - Tomitribe - Jean-Louis Monteiro, Cesar Hernandez

Ivar Grimstad - PMC Representative

Marcelo Ancelmo - Participant Member - Martijn Verburg

Werner Keil - Committer Member

Scott (Congquan) Wang - Primeton - Enterprise Member 

 

Eclipse Foundation: Tanja Obradovic, Paul Buck, Wayne Beaton

Reference: EFSP, JESP

 

Past business / action items:

  • Approval is requested for the meeting minutes from the September 16th and 23rd meetings as drafted - Approved.

Agenda:

Discussed: Is there a use case to have concurrent access to both API’s? Consider for a service release ie. 9.1? Continue as needed on the mailing list.

  • We may need maintenance releases of certain TCKs very shortly after some of their final ballots [David B.]
    • Some TCKs have spec assertion files that have invalid javax references
    • Some of the TCKs have javax in the fallback signature files.  Affects any testing on JDKs later than 11. 

Discussed: Fixups needed at some point. File bugs/issues and fix in a future release (maintenance?). 

  • Do PRs with named snapshot builds need to be replaced with a “release candidate” builds? [David]

Discussion: i) Tag the snapshot build and assure that it is kept around (accessible from a public source and never deleted). If weekly build is used, the project team needs to assure the build is suitably archived ii) Document the requirement and see that others follow. iii) Future release use only milestone or release candidate builds

Proposal: Request that the servlet team to do i) and draft text to update operations guide based on the discussion for review



I am sorry if this was revisited recently and I missed that information.

Jakarta Transactions (specification is in ballot) used a weekly build to obtain TCK results: https://github.com/eclipse-ee4j/jta-api/issues/180/ https://eclipse-ee4j.github.io/glassfish/certifications/jakarta-transactions/2.0/TCK-Results.html

If https://download.eclipse.org/ee4j/glassfish/weekly/glassfish-6.0.0-SNAPSHOT-2020-10-04.zipis not enough of an archive, please let me know if the Jakarta Transactions project need to do something.

Thanks,
Tom

  • Individual Jakarta EE specifications not in Jakarta EE 9 [Ivar]

Action: Please review the above PR and add your comments and/or support.  

_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec


_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec

Back to the top