|
We should discuss this in tomorrow's call to see whether it makes sense to update Jakarta EE TCK process. Paul, I have added this item on the agenda.
Thanks
Emily
================
Emily Jiang
Java Champion
STSM, Jakarta and MicroProfile Architect
@IBM
Liberty
Cloud Native Architect & Advocate
LinkedIn: https://www.linkedin.com/in/emilyfhjiang/
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 15:10
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>; Thomas Watson <tjwatson@xxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakarta.ee-spec.committee] Comments regarding allowing Alternate tests in TCK patch-releases
On 8/24/22 8: 42 AM, Thomas Watson wrote: 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
On 8/24/22 8:42 AM, Thomas Watson wrote:
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
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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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
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 @IBM
Liberty
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
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 <
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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
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.
Thanks
Emily
================
Emily Jiang
Java Champion
STSM,
Jakarta and MicroProfile Architect @IBM
Liberty
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
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,
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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
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
|
