| Re: [jakarta.ee-spec.committee] Comments regarding allowing Alternate tests in TCK patch-releases |
I think if we get enough of these exception requests to the specification committee to approve then it is likely that the specification committee will move to update the process for TCK service releases to avoid having such exceptions raised on a regular basis.
Sure, we can probably request exceptions for all of the new TCKs
as I'm sure the teams would appreciate being able to make further
changes if needed.
I think many are already in agreement that something needs to be improved here.
+1
https://github.com/jakartaee/jakarta.ee/pull/1496 contains a
proposal in the pull request for "A service release may update
tests as described under Accepted Challenges." (see pr for more
very specific details) and there are two other proposals in the
comments (one to allow alternate tests to be added and another to
allow TCK test changes for any TCK until the Platform
specifications are released as final). This same PR is mentioned
below as well.
Should the Specification Committee pick which of these approaches
are acceptable?
Scott
Tom
From: jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> on behalf of Scott Marlow <smarlow@xxxxxxxxxx>
Sent: Wednesday, August 24, 2022 5:16 AM
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakarta.ee-spec.committee] Comments regarding allowing Alternate tests in TCK patch-releasesThis Message Is From an External SenderThis message came from outside your organization.Hi Emily, I think we also need an update to the TCK process so that other TCK tests could be changed as needed for a service request.
If we don't make it possible to update tests via service requests I'm concerned that we won't be able to address late discovered problems.
Scott
On Wed, Aug 24, 2022, 5:47 AM Emily Jiang <EMIJIANG@xxxxxxxxxx> wrote:
_______________________________________________Hi Scott,In the last concurrency service release discussion, it was raised in the Jakarta Spec committee and the committee came up with a resolution (please see the full details in the minutes on 27th July).
Thanks
Emily
================
Emily Jiang
Java Champion
STSM, Jakarta and MicroProfile Architect @IBMLiberty Cloud Native Architect & Advocate
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
From: jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> on behalf of Scott Marlow <smarlow@xxxxxxxxxx>
Sent: 24 August 2022 09:06
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakarta.ee-spec.committee] Comments regarding allowing Alternate tests in TCK patch-releasesThis Message Is From an External SenderThis message came from outside your organization.Who is required to be present when we discuss and eventually vote on how TCK service releases can include test changes?
Please include me as a required guest for the conversation.
Scott
On Thu, Jul 7, 2022, 10:54 AM Emily Jiang <EMIJIANG@xxxxxxxxxx> wrote:
_______________________________________________Thank you, Ed, for bringing this up on the committee! I shared my following thoughts:
One issue with alternate is that the tests might make into future release. A further clean up needs to be performed before another minor/major release. We need to track this. I am not sure whether it is necessary to introduce this approach as an implementation can choose which service release they certify. If an implementation certifies against a previous tck, they can continue to do so.
Also, as mentioned before on the mailing list, I think we should have more freedom to update tests before platform or web profile releases since they will lock down which service release, they will pull in. We can fix the tcks on a particular service release and then package with platform or web profile release. Any runtime that certifies against individul specs instead web profile or platform, it can choose a particular version.
I also added to the PR as a comment.
Thanks
Emily
================
Emily Jiang
Java Champion
STSM, Jakarta and MicroProfile Architect @IBMLiberty Cloud Native Architect & Advocate
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
From: jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> on behalf of Ed Bratt <ed.bratt@xxxxxxxxxx>
Sent: 06 July 2022 19:33
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: [EXTERNAL] [jakarta.ee-spec.committee] Comments regarding allowing Alternate tests in TCK patch-releasesThis Message Is From an External SenderThis message came from outside your organization.Hi,
Just being overly diligent -- The PR discussed at the last Spec. committee meeting considers adding text allowing Alternate tests in specification patch releases. There are now a couple of proposals to describe this. One in the original, and now one offered by me, in a comment on the PR.
As a committee, we should be sure to consider first, if we are in favor of adding Alternate tests to specification patch releases. If so, then how we will describe this as part of the JESP. If we proceed, we should be prepared to adopt text that we are comfortable with, that suitably describes, limits, etc. their use.
I'm not sure everyone on the committee is subscribed to the jakarta.ee repository -- I hope you all are -- and this message is simply added noise about this proposal. This is potentially significant enough that I feel a record of this be kept in the spec.committee list.
Personally, I am happy to endorse Alternate tests. We occasionally used them previously but they were not used frequently. In later releases, it was much more common to simply exclude tests that were insufficient when the specification version was released. I would like to ensure:
- the addition of alternate tests never causes rework on the part of any vendor
- doesn't imply that a vendor's certification is different because it uses the original or alternate tests
- doesn't create additional reporting issues for vendors
- is not used by specification teams to add or change compatibility assertions that the tests verify
On a historical note, it is my recollection, we did not include Alternate tests in the original JESP simply because there was no need for them, for the first set of Jakarta tests. We simply elected not to take the time, nor expend the effort needed, to describe and agree on this, as a feature of the JESP. It seems as if the time has come to consider bringing this feature into the JESP.
-- Ed
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
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
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
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