Re: [jakarta.ee-spec.committee] : Re: Discuss proposed Resolution for el

[Scott Stark <sstark@xxxxxxxxxx>]

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