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

[Scott Marlow <smarlow@xxxxxxxxxx>]

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/238 my thoughts were to:

1. Write up the certification request issue: https://github.com/eclipse-ee4j/batch-api/issues/110 as 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