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

["Kevin Sutter" <sutter@xxxxxxxxxx>]

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:19
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>

---

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