[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-spec.committee] [External] : Re: Concurrency team is looking for guidance on release of fix that unblocks the EE 10 release
|
There are new tags for exclusions, and there are changes to tests and rearrangement of tests. It is really the 'changes to tests' that has been questioned as being against the TCK process and in need of approval.
Is there disagreement regarding the statement that there are no
new tests, this only re-arranges existing tests? If not, I wonder
if a resolution granting an exception is even necessary. We did
release a bug-fix patch for Authorization that moved the source
location of Authorization TCK tests from the Jakarta EE Platform
TCK into the Jakarta Authorization TCK. In some ways, that is a
similar type event (tests in one place were moved to another place
but there wasn't a minor release update).
So, if there isn't disagreement that this is just shuffling of
the tests, I'd be tempted to suggest we just recommend the
Concurrecy project just proceed with production of a patch
release. Skip the resolution.
-- Ed
On 7/21/2022 4:35 PM, Paul Buck wrote:
Hi Kenji,
Thanks for catching the typo.
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
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
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.
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?
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.
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"?
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.
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?
_______________________________________________
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
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee__;!!ACWV5N9M2RV99hQ!LubGktCV4kSe2JnhasvkPh4ODg1wuF9hXB07Xtdj9zFG5Jc6uS1AqJTlwuMTQ51EsZVzjwoFrM6fAeIsrJfsL07kC9SW$