| In addition I think if we did want to introduce a new class where you don't need to pass the test for the TCK to be released we'd might be smart to require each exemption requires explicit approval. Spec projects would have to make a very strong case and be prepared to get a no by default. We could write up some basic eligibility requirements for applying for the status for the feature such as it must be marked deprecated, must not have been changed in some period of time, is affecting the pace of the project and there are still implementations who want to ship it and will run the tests when they certify.
I could support putting CMP/BMP in that category. If we created this class and rules, we'd need to get the Platform spec to decide this is what they wanted to do and apply for approval. Perhaps via an updated plan review or progress review. One of the requirements could be that such a special consideration has to be done prior to a release review so a "no" is less of an impacting outcome and there is actual time to come up with a different way forward and/or a more detailed discussion.
Broadly doing it for all currently optional things would be harder as each case is very different. One could argue some of the things we've marked optional like JAXB should be required as I'm not aware of anyone not shipping it.
-- David Blevins 310-633-3852
I agree -- we would
have to (re)define what "optional" means in the Platform Spec.
I was going off of our current definition. I wonder if we would
have to use stronger terminology like maybe "deprecated". Deprecated
features are not portable and not used for ratification.This approach
would also get us closer to actually removing them from the Spec sometime
in the future since they are marked "deprecated".
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)From:
"Scott
Stark" <sstark@xxxxxxxxxx>To:
"Jakarta
specification committee" <jakarta.ee-spec.committee@xxxxxxxxxxx>Date:
07/07/2021
11:19Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] : Re: Discuss proposed Resolution for eliminating
Optional aspects of SpecificationsSent
by: "jakarta.ee-spec.committee"
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
That is the same outcome as if optional
features are removed, so I don't see how this differs. The only change
to the spec would be to say that optional features are unportable and not
used during specification ratification. I'm fine with requiring the removal of
optional features from specifications as well. On Wed, Jul 7, 2021 at 11:15 AM Kevin
Sutter <sutter@xxxxxxxxxx>
wrote:Thanks for the
pointers to the EFSP Issues, Scott.
I think this is a slippery slope when we're going to define a Ratified
CI as the one that passes the TCK -- regardless if the optional features
are implemented or not. Let's pretend we have a CI that only implements
the required features, nothing else (no entity beans, no web services,
no jaxb, etc). Are we going to allow that CI to be used for ratification
of the Platform Spec? If we do, then how are we going to determine
whether the optional features are implementable or testable?
I can understand that we're trying to compromise on a solution here.
But, I don't think we should entirely remove the idea of not requiring
optional features to ratify the Platform Spec.
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
From: "Scott
Stark" <sstark@xxxxxxxxxx>
To: "Jakarta
specification committee" <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: 07/07/2021
10:40
Subject: [EXTERNAL]
Re: [jakarta.ee-spec.committee] : Re: Discuss proposed Resolution for eliminating
Optional aspects of Specifications
Sent by: "jakarta.ee-spec.committee"
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
A modification to the EFSP on this topic is underway. That requirement
will be removed and left to the working groups as per these two issues
on changes going into EFSP 1.3:
https://github.com/EclipseFdn/EFSP/issues/22
https://github.com/EclipseFdn/EFSP/issues/42
Other than the uncertainty of what a given profile requires, the major
practical impact of optional is that it introduces a bottleneck on
testing features that do not have unanimous support. So either remove
that or remove optional features. The former is a compromise the
addresses the request to have a measured removal of optional from
specifications.
On Wed, Jul 7, 2021 at 8:37 AM Kevin Sutter <sutter@xxxxxxxxxx>
wrote:
>
> I think we're shifting the conversation... We started with trying
to define a means of removingoptional aspects of the Platform Specification.
But, now we're talking about removing the necessity to test optional
aspects of the Platform. Totally different conversation.
>
> Removing the necessity to test the optional features of a Spec by
a ratified Compatible Implementation would require an adjustment to the
EFSP:
>
> "A Specification Version must identify at least one Compatible
Implementation under an Open Source License that implements all optional
elements of the Specification and fulfills the requirements of all elements
(including optional elements) of the TCK."
>
>
> ---------------------------------------------------
> Kevin Sutter
> STSM, Jakarta EE and MicroProfile architect @ IBM
> e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
> phone: tl-553-3620 (office), 507-253-3620 (office)
> LinkedIn: https://www.linkedin.com/in/kevinwsutter
>
> Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
>
>
>
> From: "Scott Stark" <sstark@xxxxxxxxxx>
> To: "Jakarta specification committee"
<jakarta.ee-spec.committee@xxxxxxxxxxx>
> Date: 07/06/2021 17:30
> Subject: Re: [jakarta.ee-spec.committee]
[External] : Re: Discuss proposed Resolution for eliminating Optional aspects
of Specifications
> Sent by: "jakarta.ee-spec.committee"
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
> ________________________________
>
>
>
> Correct. On Jul 6, 2021 at 3:04:09 PM, David Blevins <dblevins@xxxxxxxxxxxxx>
wrote: On Jul 6, 2021, at 6:33 AM, Scott Stark <sstark@xxxxxxxxxx>
wrote: The minimum compromise approach Red Hat would support would be to
remove any
> Correct.
>
> On Jul 6, 2021 at 3:04:09 PM, David Blevins <dblevins@xxxxxxxxxxxxx>
wrote:
> On Jul 6, 2021, at 6:33 AM, Scott Stark <sstark@xxxxxxxxxx>
wrote:
>
> The minimum compromise approach Red Hat would support would be to
remove any optional TCK sets as a requirement to ratify a profile specification.
Just kicking this can down the road for another release without some remediation
of the current burden optional features place on the ratification process
is not acceptable.
>
> Confirming I understood correctly. You would support an approach
where the CMP/BMP TCK tests are still present in the TCK, but not required
for ratification. Of course any implementation that implements CMP/BMP
would still be required to pass those tests.
>
> Did I read that correctly?
>
>
> -David
> _______________________________________________
> 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://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________ jakarta.ee-spec.committee mailing list jakarta.ee-spec.committee@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
