| Re: [jakarta.ee-spec.committee] Concurrency team is looking for guidance on release of fix that unblocks the EE 10 release |
The Jakarta EE TCK Process is authored by and owned by the Specification Committee, we can therefore authorize an exception by way of a ballot. In the future, we could consider a revision to the TCK Process if we thought it was warranted based on other projects asking for the same exception.
_______________________________________________Paul,
Thanks for drafting a resolution.
There is a typo:
Jakarta EE Test Process -> Jakarta EE TCK Process
I have no objection about the resolution,
but I wonder if the specification committee has a power to grant the exception against TCK Process.
Or do we need to change TCK Process itself ?
-Kenji Kazumura
From: jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On Behalf Of Paul Buck
Sent: Thursday, July 21, 2022 11:45 PM
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Concurrency team is looking for guidance on release of fix that unblocks the EE 10 release
I have drafted a backgrounder statement and a resolution, if there are no objections, I will get the ballot underway on our public mailing list on Friday (22nd).
Background: Concurrency was added to the Web Profile for Jakarta EE 10, therefore existing Concurrency tests needed to be added to the Web Profile TCK. The existing Concurrency tests were deployed in EAR files and used remote EJB, neither of which are supported in the Web Profile. The tests in scope here are not new tests, they are existing tests that have been updated to no longer depend on EAR or remote EJB, there is no change to either the functionality or API testing. The Jakarta EE Test Process states that a "... service release which updates the exclude list MUST not have test additions or updates". Given there are no additions, and the updates have no effect on functionality or API testing, granting the Concurrency project an exception to update their TCK is service release is reasonable.
Resolution: It is resolved that the Jakarta EE Specification Committee grants a Jakarta EE TCK Process exception to the Jakarta Concurrency project to update the tests in their Jakarta Concurrency 3.0 TCK to no longer depend on EAR or remote EJB when executed in environments that does not support these technologies, and deliver these changes as a service release.
On Tue, Jul 19, 2022 at 7:37 PM Paul Buck <paul.buck@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Right then, is there a spec committee representative that is able and willing to draft a suitable resolution with supporting preamble/rationale for this exception that the spec committee can consider, discuss and then ballot on?
On Tue, Jul 19, 2022 at 5:51 PM Scott Stark <sstark@xxxxxxxxxx> wrote:
The changes would be more associated with the TCK process since the concurrency TCK is what is being updated. There are no changes to the specification or APIs.
There it says a "... service release which updates the exclude list MUST not have test additions or updates". The current proposal would violate that. The concurrency team is seeking an exception to this since the concurrency TCK was not validated against any Web Profile release as part of the concurrency component specification and now standalone TCK.
On Tue, Jul 19, 2022 at 12:59 PM Paul Buck <paul.buck@xxxxxxxxxxxxxxxxxxxxxx> wrote:
I draw your attention to the Jakarta EE Specification Committee Operation document section section on Creating a Final Service Release Specification wherein it documents: "There is no formal release review required for a Specification service release (x.y.z) as long as the JESP definition of a “service release” is adhered to. That is, no functionality changes or increase in IP scope are permitted in a service release."
So the question here I think is does "...fixing the current Web Profile set of TCK tests in a 3.0.x release so as not to lose coverage and unblock the platform release." adhere to the JESP definition of a "service release"?
... Paul
On Tue, Jul 19, 2022 at 12:10 PM Scott Stark <sstark@xxxxxxxxxx> wrote:
To follow up on this after the platform call today, what the Concurrency team is asking for is no opposition to fixing the current Web Profile set of TCK tests in a 3.0.x release so as not to lose coverage and unblock the platform release. Barring any opposition to the approach in the next couple of day they will assume this approach will not be challenged.
If there is opposition, the mechanism for creating a minor release of a TCK needs to be clarified at the next specification committee meeting. As I understand the current process, it would require a new minor project release which would entail a project plan, voting, etc.
On Jul 18, 2022 at 4:48:45 AM, Scott Marlow <smarlow@xxxxxxxxxx> wrote:
As per https://www.eclipse.org/lists/cu-dev/msg00389.html, Concurrency team would like to know if they can release a service release of the TCK with the change that fixes Web Profile support. I think that this blocks EE 10 from going final.
Do they need to start a new ballot or a service release?
Scott
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee