Re: [jakartaee-spec-project-leads] Questions on the intial certification

["Scott Kurz" <skurz@xxxxxxxxxx>]

Thanks Scott, Kevin for your input.

So from the spec/API perspective, I'm just going to use my jbatch 2.0.0-M7 milestone release to certify as the CI.

And since I don't particularly care about certifying jbatch 2.0.0 per se... I don't really ever need to.

That makes sense.. I'll go rework the certification issue and update the spec PR shortly.

------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

"Kevin Sutter" ---08/04/2020 01:12:02 PM---Correct, Scott Stark. Any public version should be fine for the CI. -------------------------------

From: "Kevin Sutter" <sutter@xxxxxxxxxx>
To: JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Date: 08/04/2020 01:12 PM
Subject: [EXTERNAL] Re: [jakartaee-spec-project-leads] Questions on the intial certification request using a pre-release impl
Sent by: jakartaee-spec-project-leads-bounces@xxxxxxxxxxx

---

Correct, Scott Stark.  Any public version should be fine for the CI.


---------------------------------------------------
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:        Scott Stark <starksm64@xxxxxxxxx>
To:        JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Date:        08/04/2020 11:52
Subject:        [EXTERNAL] Re: [jakartaee-spec-project-leads] Questions on the intial certification request using a pre-release impl
Sent by:        jakartaee-spec-project-leads-bounces@xxxxxxxxxxx

---

The only part of this I don't agree on is any need for a final version of the CI. Any public version should be fine.

On Tue, Aug 4, 2020 at 10:59 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Scott Kurz,
I think your proposed process sounds very reasonable and consistent with what we did in Jakarta EE 8.  Wherever possible, each individual Specification Project should be preparing their individual TCKs and Compatible Impls, and doing the "final" verification testing.  You should be using the "final" versions of the APIs, TCKs, and CIs per the staging processes.  None of these artifacts should be made available via Maven until the ballots are completed.

Each of these individual TCKs feed into the Platform TCK.  I look at that as a separate process.  That is, the Batch Spec PR should not be required to wait until the Platfrom Spec PR is complete before initiating their ballot.  If there are some tweaks that need to be done to the Batch TCK in order to merge with the Platform TCK (post the Batch PR ballot), then these should be accomplished via a third digit update (ie. 2.0.x of the TCK).

Hope this helps!  And, thanks for asking these questions.  I'm sure there are others with similar thoughts...

---------------------------------------------------
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:        "Scott Kurz" <skurz@xxxxxxxxxx>
To:        JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Date:        08/04/2020 09:09
Subject:        [EXTERNAL] Re: [jakartaee-spec-project-leads] Questions on the intial certification request using a pre-release impl
Sent by:        jakartaee-spec-project-leads-bounces@xxxxxxxxxxx

---

Thanks Scott for replying.

I had only been discussing the pre-release compatible impl, not the Batch TCK. 

But I did have something like you mentioned in mind if were any TCK doc PRs do come in: that we'd accumulate them, and then do one final certification re-run at the end. 

------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

Scott Marlow ---08/04/2020 09:59:13 AM---Thanks Scott for raising this. From a Standalone TCK staging perspective, Jakarta Batch does contro

From: Scott Marlow <smarlow@xxxxxxxxxx>
To: JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Date: 08/04/2020 09:59 AM
Subject: [EXTERNAL] Re: [jakartaee-spec-project-leads] Questions on the intial certification request using a pre-release impl
Sent by: jakartaee-spec-project-leads-bounces@xxxxxxxxxxx

---

Thanks Scott for raising this.  From a Standalone TCK staging perspective, Jakarta Batch does control its own standalone TCK, however, from a process point of view, I think it should be the same as others.

After feedback (regarding contributors needing more time to review TCK documentation than a weekend) yesterday on the Jakartaee-tck mailing list, I do want to give some suggestions for Jakarta Batch Standalone TCK, as well as all of the others.

With regard to Standalone TCK deliverables, we can easily stage new builds of each Standalone TCKs, however we can only promote a specific versioned Standalone TCK once (with the last promoted TCK version targeted for EE 9 final release).

So from a TCK perspective, I propose that contributors review TCK documentation and create pull requests over the next N days, where N is to be discussed further (perhaps N could be 10 calendar days including non-working days or some other duration yet to be discussed).  

Whatever N is for the final date to create TCK documentation pull requests by, each SPEC API ballot could work off of an initial promoted TCK (e.g. assuming no TCK test failures and SPEC API lead approves current TCK doc).  If subsequent TCK documentation pull requests come in after the SPEC API ballot, the SPEC lead (or TCK team) could push a new staged Standalone TCK update that could then be promoted with the updated TCK documentation.

Would ^ help with the chicken + egg issue?

Scott

On Tue, Aug 4, 2020 at 8:53 AM Scott Kurz <skurz@xxxxxxxxxx> wrote: 
We know there is some circular dependency in this process ( "chicken/egg").. e.g. the compatible impl can't be finalized until spec and dependencies are finalized yet the compatible impl is needed to approve the spec in the first place.

So for the Batch 2.0 PR: https://github.com/jakartaee/specifications/pull/238my thoughts were to:

1. Write up the certification request issue: https://github.com/eclipse-ee4j/batch-api/issues/110as if I were using the final, v2.0.0 "jbatch" implementation release.
2. Run the staged TCK against a pre-release v2.0.0 identified by source tag (but not maven release)
3. Once the API, spec, and TCK are finalized along with dependencies, release the v2.0.0 "jbatch" implementation.
4. Re-run the TCK against v2.0.0 jbatch impl.
5. Add a note to the certification request issue?
----

Any concerns? Does this seem reproducible enough? 

Would it be better to do a milestone release of the jbatch impl, and then write up the certification request issue against this milestone release? Does it matter if the impl isn't using final versions of Jakarta dependencies (if it did, I'd have to wait until the Transaction API is staged). Any rules on whether a compatible impl can use milestone releases? 

I'd think 4, 5, above would be more about certifying the jbatch 2.0.0 impl than necessary to finalize the spec/API... which would already have been approved at that point, so maybe that's not necessary or should NOT be done (i.e. don't tamper with the historical record)?

I don't want to go overboard with rigor if this isn't really necessary and in line with what other specs are doing, but trying to be transparent and not sweep anything under the rug either.

Thanks,
------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads


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



_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads


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