| [jakartaee-platform-dev] [DISCUSS] Introduce "favored specification" concept to Platform specification |
|
Let's drive this forward. So far eight individuals have responded to this thread. On the question of the merit of the general idea, six were in favor and two opposed. I think that is enough consensus
to carry the idea forward. On the specifics of what to call the idea, there was no clear consensus. I'll exercise my executive authority and suggest Tom's "Platform Prospective Specifications". On the specifics of how to judge what can be included, I'll exercise my executive authority and suggest David's list: DB> - Specification is final (or will be when EE X is released) DB> - Specification can be implemented on EE X DB> - Specification TCK can run on EE X I've created this draft PR with the proposed text added to the Platform specification.
https://github.com/jakartaee/jakartaee-platform/pull/749 . I'll keep this open for comments for a while. I'll consider the comments and then merge it. I observe that Jakarta No SQL does not meet at least one of the requirements in David's list. If the time comes that EE11 is ready to be done, and it still does not meet those
requirements, I'll remove it. @Otavio! Consider this a kick in the pants to meet the requirements! You're at 1.0.0b7 now. Keep going toward 1.0.0! Also, get that TCK done. Thanks, Ed Summary of discussion. Brian Stansberry wrote: B> I'm in favor of this idea. I'm in the camp of not wanting to see B> inclusion in the platform being used to drive adoption of specs B> that otherwise haven't gained adoption. But Jakarta doing some B> cross-promotion of its specs sounds fine. B> If we formalize what the list is, that may help with the name. In B> concrete terms, for EE 11 I believe we're talking about any of B> Jakarta MVC, Jakarta Data and Jakarta NoSQL that aren't approved B> for inclusion in the platform. So in abstract terms, is that what B> we're talking about? Specs that came to a vote for inclusion in the B> platform but the vote didn't pass? In that case the Candidate term B> seems reasonable. B> If we specifically vote for which specs are in this list, separate B> from any vote for inclusion in the platform, then a term like B> favored feels better to me, as the vote would have to pass, B> indicating general 'favor'. A 'candidate' that received little B> support for inclusion in the platform may not really be 'favored'. B> We also discussed listing all the standalone specs. If we went that B> route 'favored' would be problematic. We'd also have to work out B> how to deal with the formerly optional standalone specs that are B> still active but have been removed from the platform. David Blevins wrote: DB> I like the idea. Another aspect for discussion is "what are the DB> requirements for being listed." DB> Some high-level thoughts on being included: DB> - Specification is final (or will be when EE X is released) DB> - Specification can be implemented on EE X DB> - Specification TCK can run on EE X DB> The idea being we guide people to the exact versions of standalone DB> specifications that have done work to ensure they can be DB> implemented or run on EE X. DB> With that kind of definition, maybe simply calling them DB> "Compatible Specifications" is apt. Not a firm name suggestion, DB> just spit-balling. DB> If we were to add a section like this, it would make sense to ask DB> Platform implementations to mention in their CCR any such specs DB> they implement so users can favor those Platform implementations. Ondro Mihaliy wrote: OM> I agree with the idea. There are some specs which obviously have OM> some traction and have been released already or are close to OM> having a 1.0 version but have not been included in the Platform. OM> I just don't like the term "favored". It sounds like they are OM> already in the Platform and are just endorsed to use in the future OM> (opposite of obsolete). I think it would be better to call them OM> candidate, or incubator specs, or something like that, to indicate OM> they are active and considered for inclusion in the Platform in OM> the future, while other specs are not ready to be considered to OM> become part of the Platform yet. Or we could use both terms - OM> candidate for the specs considered for inclusion in the Platform, OM> and incubator for the specs that are still not ready yet. Then we OM> can easily promote both lists of specs without confusion. DB> If we were to add a section like this, it would make sense to ask DB> Platform implementations to mention in their CCR any such specs DB> they implement so users can favor those Platform implementations. OM> I would go even further and mention the implemented OM> favored/candidate specs, and maybe also other non-Platform specs, OM> on the CCR summary page at OM>
https://jakarta.ee/compatibility/certification/10/ so that people OM> can easily compare which implementations provide which specs. Emily Jiang wrote: EJ> I support the idea to add such a section to drive some tractions EJ> to the standalone specifications. I don't feel we should say EJ> "Candidate xx" nor "Favored". I feel the wording like "Additional EJ> Specifications" might be more appropriate. Tom Watson wrote: TW> I suggest Platform Prospective Specifications. These are stand TW> alone specifications for which the Platform Specification project TW> considers as prospects for inclusion in a future version of the TW> Platform specification. Jan Westerkamp wrote: JW> I think this is an example of good intentions generating bad outcome: JW> "is this a good idea or not": JW> A specification is a technical document defining requirements on JW> behaviour of technical implementation, that in must be expected or JW> in some cases may be expected - in the best case this can be JW> tested and certified with the corresponding TCK. Personas get JW> addressed by a specification document are spec developers, JW> implementation developers and interested, mostly experiences JW> application developers - NOT POs, CEOs, CIOs etc. To be clear: JW> This is NOT a marketing or product management document to promote JW> things - this is out of scope of a specification document! When JW> we do a good job, most developers and users don't even need to JW> read it, they only need to read the digested form like a magazine JW> article, blog post, Javadoc or listen a conference talk to apply JW> the technology in an intuitive way. JW> Additionally, with the intended release cadence of two years of JW> the Jakarta EE Platform specification, such promoting information JW> might outdate in an different, much shorter time frame. JW> We should do promoting on the Marketing Committee channels like JW> the website to point out clearly, what is a mature or experimental JW> technology besides the Platform and which version can be combined JW> with which Platform version instead. Using WG documents like the JW> yearly Program Plan might be good too. JW> The specification should only contain in scope specs, otherwise JW> what should be included then and where to stop? Jakarta JW> stand-alone specs (which ones)? MicroProfile? Spring? Or regarding JW> front-end technologies, what about Vaadin? JW> To bring it in scope of the spec it need to be offered by the JW> majority of the implementation vendors (push principle), the user JW> demand (pull) or both (best case). What is qualifying a sepc to JW> be listed in the intended way? Developer survey result, WG Member JW> voting, Committer or community voting, download rate? JW> Please let us add professional software engineer information into JW> the spec document only and do industry politics somewhere else, JW> while not mix up the scope of documents/channels! JW> "what should we call this thing": JW> The only thing I could imagine is adding an out-of-scope section JW> to the spec and pointing out, that there is the Jakarta Platform JW> spec with it's Profiles documented here and there is a wider set JW> of Jakarta as a platform in a sense of a set of technologies, that JW> go beyond the Jakarta Platform spec itself, including additional JW> specs. This section could give some clarification what is meant JW> with "platform" and "sand-alone", which both are potential JW> misleading names. May be a (stable) link to theses specs listed JW> (and maintained) on a website (https://jakarta.ee) could be JW> added - but not more than that. JW> Everything else adds confusion and only blows up the spec document JW> size for the intended users of it. Steve Millidge wrote: SM> I completely agree with Jan’s view below. The specification SM> document itself is a technical reference document and shouldn’t SM> reference specifications not in the platform (maintenance SM> nightmare). SM> If we are strictly following a release train model we do not know SM> what could be in the platform next release. SM> There are lots and lots of better ways to promote wider Jakarta EE SM> specifications. SM> Jakarta EE Specifications | The Eclipse Foundation is the source SM> of information of all specifications. Kito Mann wrote: KM> This is a bit of a tangent, but I think we should consider the KM> scope of the individual specs to be broader than you have KM> specified, Jan. While working on updating the tutorial, we have KM> discussed when a developer would need to read the actual KM> spec. Some specs are written to be very accessible to the average KM> developer, and some are not. I think we should move towards a KM> model where the specs are readable documents for those who want to KM> apply the technology, not just those who need to implement KM> it. That way, articles, tutorials, talks, can provide enough info KM> to get started, but people who need reference information can KM> easily read the spec. |
edburns@xxxxxxxxxxxxx | office: +1 954 727 1095 | Calendar Booking:
https://aka.ms/meetedburns | | Please don't feel obliged to read or reply to this e-mail outside | of your normal working hours. | | Reply anonymously to this email:
https://purl.oclc.org/NET/edburns/contact |