I'd attend next week's meeting to discuss, but it looks like it's the alternate 6am time for me.
What do people think about taking a bit of both approaches we've discussed: allowing multiple CIs within reason; reforms on how we treat optional requirements.
Some concerns I have with either approach and high level ideas on how they might be addressed.
- Complexity from too many CIs. If we needed 4 or 5 CIs to complete a vote that is clearly too many. This would be an obvious sign the specification has gone too far with optional features. A potential remedy would be to limit the number of CIs to say 2 or 3. Perhaps 2 is fine as standard practice, 3 by exception and not for more than say two releases in a row. We actually used two CIs for Jakarta EE 9.1 as we had different releases of GlassFish.
- Lack of visibility on support of Optional features. Neither users nor us have a good idea of how many optional features we have and who implements them. I think a lot of our issues stem from this; we can't see the breadth of the problem so the the "right thing" can't happen organically. A potential proposal is that each spec must keep an inventory of optional features and each CCR must accurately report which they do and do not implement. If a spec does not have an inventory of optional features they are ineligible for a release vote.
- Excessive optional features. If say 10% of your TCK is optional features, that's ok. If over 50% of your TCK is optional as is the case for EJB that's clearly too far. There are a few remedies for this. If a feature has been marked optional but in fact everyone implements it (EJB 2.x views), then it should not be optional. If a feature is very very large and needs to become legacy but is widely supported (CMP), it could become its own spec/profile. Of course removing unsupported optional features is always a potential remedy. A potential proposal could be to establish a metric; if more than 20% of your TCK is optional, you are ineligible for a release vote until you remedy the situation (using any combination the spec project deems fit).
- Too many profiles. At a certain point there can be too many profiles and 1) this becomes just another word for optional while 2) potentially still not capturing/accommodating the potential combination of features a user needs. Rather than create "legacy" profiles we could allow vendors to ship specifications above and beyond what is included in the Platform, Web Profile or Core Profile. Meaning you could have say a Web Profile + JMS implementation. Large legacy features like CMP would be split into separate specifications and can be included by implementations in that way. The corresponding TCKs would still exist, need to be passed and would have to be maintained by those who chose to continue supporting/shipping that spec; this ensures the tests don't decay as we move from Java 8 to 11, or 11 to 17, or refactor our TCK harnesses.
The above are just some high level thoughts and are not my ideas. I'm attempting a "greatest hits" of all our ideas so if you see things you've advocated, that's me attempting to include your awesomeness and blend the best of everything put forward.
For all the "ineligible for a release vote" statements, we could potentially have a grace period and or the ability to request a one-time exception or a rule change. All this would be in our JESP. If we decide exceptions can be made, those would all be written down in a dedicated document that tracks all exceptions made for all specs, including if they are one-time or ongoing. We could use that over time to track if we need to adjust our rules. Things like using two versions of GlassFish would have been written in our exceptions document and could be leveraged in conversations like this. We could use it as a data point to demonstrate even GlassFish is having a hard time meeting the "one implementation must meet all requirements" rule.
--
David Blevins
http://twitter.com/dblevinshttp://www.tomitribe.com310-633-3852
On Jun 23, 2021, at 1:12 PM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Scott,
We decided at the Spec Committee that we would start the conversation on the private email first -- to ensure that we have a consistent, agreed-to, defined approach before sending it to a wider audience. Based on these email discussions, I'm not sure we're at that point yet. I know we don't need 100% consensus, but I think it would be good to ensure that we have a super-majority approval on the direction. Should we take a quick straw poll of the Spec Committee members? If we have that super-majority, then we could go ahead with the wider audience. If not, then maybe we need to iron things out further via email and/or next week's meeting?
---------------------------------------------------
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: 06/17/2021 12:43
Subject: [EXTERNAL] Re: [jakarta.ee-spec.committee] Discuss proposed Resolution for eliminating Optional aspects of Specifications
Sent by: "jakarta.ee-spec.committee" <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
Also, this is on the private list. I was going to point to the email for some of our project developers, but found that it was inaccessible by them (and somehow me as well) when trying to access https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
On Jun 16, 2021 at 1:59:07 PM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
On our Specification Committee call today, we discussed a proposed Resolution (prepared by Dan and Paul) about eliminating the use of Optional features in Jakarta EE Specifications. We decided that we should discuss the Resolution via the private mailing list for the next seven days (max). At that time, hopefully enough input would produce a version of the Resolution to post to a wider audience (Spec Project Leads and/or public Spec Committee mailing lists). Again, hopefully, we would get enough input from these two mailings to allow for a ballot on the Resolution at our next Spec Committee meeting on the 30th.
First, for background, if you are not familiar with the back story for this Resolution, please review this document:
https://docs.google.com/document/d/1O5MnbQRn8RWkM4BpJth9VqGfhKLBZfFzK_fpIyZ_2vw/edit
(BTW, before we externalize that document to the Spec Project Leads and/or public Spec Committee mailing list, we should resolve any outstanding comments... Dan,I will leave you in charge of that activity.)
The proposed resolution is just a slightly re-worded version of option #1 in the referenced document.
• DRAFT RESOLUTION: To eliminate marking any Jakarta EE Specification feature as optional in some future release of each Jakarta EE Working Group Specification, including and possibly starting with the Jakarta EE Platform Specification Release 10. All remaining features would be required.
• Clarifying text to the proceeding resolution: The process would be to mark all optional features in the current release as “Deprecated” in a new Minor release (Release 9.2), and in a subsequent Major release (not necessarily the very next Major release) eliminate the Deprecated feature completely from the Jakarta EE Platform Specification. Eliminating these Deprecated features is not retroactive to earlier released specifications, which will continue to exist. As implied, “Deprecated” will be defined as a way of marking a feature as on the path to complete elimination from some future release, and it indicates to the public “this feature is going away”. This two-step process provides a formal communication mechanism within the specification itself for the Working Group to signal to the community that a feature will definitely be removed from a future release. The intent is to mark current features marked as “Optional” as “Deprecated”, but in the future even “Required” features could be marked as “Deprecated” should the Working Group decide to prune little used features from the platform. This two-step process will take longer but will also give consumers of the platform a longer runway to plan for and deal with the elimination of the feature should they wish to consume that future platform release.
Comments and suggestions are welcome! Thanks!
---------------------------------------------------
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)
_______________________________________________
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
