Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] [Ballot] Optional Features Resolution



I declare this ballot complete and approved. The summary of the votes is below:

RepresentativeRepresentative for:Vote
Kenji KazumuraFujitsu+1
Dan Bandera, Kevin SutterIBM+1
Ed Bratt, Dmitry KornilovOracle-1
Andrew Pielage, Matt GillPayara+1
Scott Stark, Mark LittleRed Hat+1
David Blevins, Jean-Louis MonteiroTomitribe-1
Ivar GrimstadEE4J PMC+1
Marcelo Ancelmo, Martijn VerburgParticipant Members+1 *
Werner KeilCommitter Members-1 *
Dr. Jun QianEnterprise Members+1
Total6


* - vote arrived after the ballot was closed so was not included in the tally.


Thanks ... Paul



On Thu, Aug 5, 2021 at 6:27 AM Werner Keil <werner.keil@xxxxxxx> wrote:

-1

 

I agree with what David wrote here and also think optionality (or whatever other words are used in those cases) helps even for new specs or features to provide flexibility to implementors, e.g. being able to support REST/MVC or the Servlet/JSP/JSF stack just to repeat one example of many.

 

Werner

 

Von: David Blevins
Gesendet: Mittwoch, 4. August 2021 21:21
An: Jakarta specification discussions
Betreff: Re: [jakarta.ee-spec] [Ballot] Optional Features Resolution

 

-1 (Tomitribe)

 

We would also be in favor of a resolution that strongly discourages new optional features.  The most likely outcome of this resolution would be that the same optional behavior will still occur, just now called profiles instead of features.  The EJB spec for example has 3 optional groups.  In future specs we can expect these to simply become optional profiles, an inevitable explosion of profiles and no real change in behavior.

 

We do think there is good reason to have some flexibility to implementors, whether it be called an optional feature or optional profile.  Optionality (feature or profile) is useful for introducing innovative new ideas that might not initially gain 100% support from all implementations.   Optionality (feature or profile) is useful for deprecating old functionality to make room for new implementations.

 

We are completely on the same page that in our current state is there is far too much optional behavior and we do not want to see more without some very good reasons.  Rather than ban one form of optional behavior (feature) and leave others open and unchecked (profile), we'd prefer a resolution whereby specification projects must seek approval for any optional behavior (feature or profile) in either a Plan Review or a Progress Review.  We think this would create a needed dialog with spec projects, force us to deal with the implications of our desires for no optional behavior and allow us to learn lessons and adjust course.

 

Assuming this resolution passes, a possible amendment could be:

 

RESOLUTION: The Jakarta EE Specification Committee resolves that no new optional features or profiles may be added in Jakarta EE 10 and beyond in component, Platform, or Profile specifications without prior approval via a Plan Review or Progress Review.



On Jul 28, 2021, at 7:46 AM, Paul Buck <paul.buck@xxxxxxxxxxxxxxxxxxxxxx> wrote:

 

 

Greetings Jakarta EE Specification Committee,


I need your vote to approve the following resolution:

 

RESOLUTION: The Jakarta EE Specification Committee resolves that no new optional features may be added in Jakarta EE 10 and beyond in component, Platform, or Profile specifications.

 

This is a seven day ballot, ending on Wednesday, August 4th. Community input is welcome, but only votes cast by Specification Committee Representatives will be counted.

The Specification Committee is composed of representatives of the Jakarta EE Working Group Member Companies (Fujitsu, IBM, Oracle, Payara, Red Hat, Tomitribe, and Primeton), along with individuals who represent the EE4J PMC, Participant Members, and Committer Members.

Specification Committee representatives, your vote is hereby requested. Please respond with +1 (positive), 0 (abstain), or -1 (reject).  Any feedback that you can provide to support your vote will be appreciated.

 

Thanks ... Paul

_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec

 

 

_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec

Back to the top