I guess the alternate approach is propose a new minor release but
I guess that would take a plan ballot followed by a release
ballot. That would take, minimum 4 weeks (two weeks for each
ballot). If we could do these together, maybe we could get this
done in two weeks.
Other than a resolution granting an exception, has any other
solution been proposed, maybe in the committer team discussions?
It seems, at this point, we might also consider taking up this
exception by in-person vote at the next committee meeting. Or, is
e-mail approval the only way for things like this?
-- Ed
On 7/21/2022 7:27 PM, Scott Stark
wrote:
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.
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. TheJakarta
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?
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.
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.
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?