Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] [External] : Re: Ratified Implementations and special designation in the eyes of users

I wasn't on the call so please allow me to inject my thoughts --

the implementation (or implementations) that is (or are) willing to work with the specification project on the speculation that the evolution of the specification will become useful, and who are willing to work under the project constraints and timelines set by the community, do, in my opinion deserve some special mention. That team or and/or their sponsoring organization is putting themselves and their effort behind something completely speculative and community planned until the final ballot is approved.

Those who come after, while certainly supportive and welcomed, have the benefit of adhering to their own timelines and project requirements, not those determined by our community. They are not obligated to apply the inevitable last minute changes and rework from changes that always come up as everything comes to a close. We welcome later compatible implementation contributions to the specification in the way of bug-fixes, test challenges, etc. but these are not provided under the same constraints and onus as the implementations that agree to work under the specification project delivery requirements.

Another obligation of the implementation(s) that are used for ratification is, those implementations is supposed to live "forever" (so one could go back and verify how the Spec. team verified that the spec. could be realized). I don't think subsequent implementations have any such obligation.

I don't see this suggestion so, I'll add one more to the list:

Under the first heading (the Spec. name and version) on the specification page add all implementations that are included as part of the ratification.

Under the heading Compatible Implementations -- all compatible implementations can be listed (including those used for ratification) in whatever order we like.

So, initial compatible implementations are listed with the rest of the Specification required materials and if an initial compatible implementation were to ask we replace it's certification listing with a newer release -- that could be accommodated (if that vendor wishes) under the 'compatible implementations' heading without displacing the material used for ratification.

Regardless how we implement this, I think these initial implementations do deserve some recognition.

-- Ed

On 2/10/2021 4:23 PM, David Blevins wrote:
To simply this, it might be helpful for me to get a better understanding of what goals are trying to achieve with the star.  Hopefully I can be more helpful in suggesting other solutions.

Thanks again to everyone for the responses -- they are appreciated.

David Blevins

On Feb 10, 2021, at 4:15 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:

Agreed our current rules do make one implementation special as it does have to implement all optional parts.  We have it on our 2021 plan to address that because it isn't fair; particularly to the one implementation that has to implement all the optional parts.

If the star meant "implements all optional parts", then that could be fair as anyone could get the star if they put in the work, even if they did it slowly and came later.  It might even motivate them to implement all optional parts to earn the ability to stand out despite being lower in the list.  I'd still probably prefer to handle that in the public test results page because everyone's optional statuses are likely nuanced, but an all or nothing approach is at least consistent and I could accept it as fair.

Understood that the list is ordered by the dates everyone is certified.  I'm ok with that.  If we did alphabetical that'd pretty much put Apache Foo projects at the top of every list, which I also don't think is fair.

If the star meant "we used these for the ballot", then my comments would be having stars on the first entries in addition to them being ordered by date (who has more resources) really makes that much tougher on those of us at the bottom of the list.  It's already an advantage being first to market and a disadvantage not even being listed for months (or years in our case).  If we can avoid bringing stars in as well it would make a positive impact on our morale and be greatly appreciated.

Very happy to discuss any aspect of this and greatly appreciate everyone's time.  Very open to discussion and willing to make compromises.

David Blevins

On Feb 10, 2021, at 2:35 PM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:

Unfortunately, the compatible implementation(s) used to ratify or certify the Specification version is special.  The compatible implementations have to contain and test all of the required *and* optional aspects of the Specification.  Compatible implementations that come after the certification may or may not have the optional aspects of the Specification.  So, to pretend that all compatible implementations are neutral is not fair.  And, tbh, the ordering of the compatible implementations implies some form of "superiority" or, at least, non-neutrality.  How do we get around these shortcomings?  We discussed this at length, and the approach proposed with the asterisk (*) seemed like a good compromise.

FWIW, I didn't even want to list any additional CIs on these Specification pages.  I thought (and a few others on the call agreed) that the Compatible Implementation listed on these Specifications pages were the ones used to certify with.  Period.  Any other listing of additional Compatible Implementations would be listed on the respective github pages or wiki of the Specification Project.  But, others on the call thought this was confusing to look in multiple locations for the compatible implementations.  So, we compromised on the above approach.

Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    

Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)

From:        David Blevins <dblevins@xxxxxxxxxxxxx>
To:        Jakarta specification discussions <>
Date:        02/10/2021 13:12
Subject:        [EXTERNAL] [] Ratified Implementations and special designation in the eyes of users
Sent by:        "" <>

I appreciate there was consensus on today's spec committee call to mark the implementation used for certification with a star.  We also commented that if we would alternate the time of the meeting, we should do more over email, so hopefully my feedback is welcome despite missing the meeting.

Can we find another way to document the implementations used for the vote?

I have many concerns about the concept of RIs.  A big one is the years of difficult experience competing against an implementation the public sees as special or more official than yours.  The fundamental tenant of Advance Implementation Neutrality is to make sure we're not doing that.

If we want to document the implementations used for the Release Review, can we simply include a link to the relevant CCRs in the "Release Review" section of the page?  It could be right under the vote totals after the text "The ballot was run in the mailing list.  The CCRs used for the ballot were: [link1] [link2]"

This would have it documented, but the list of implementations would look neutral and one would not stand out over the other.


David Blevins
_______________________________________________ mailing list
To unsubscribe from this list, visit

_______________________________________________ mailing list
To unsubscribe from this list, visit

_______________________________________________ mailing list
To unsubscribe from this list, visit;!!GqivPVa7Brio!Jim_p6_C9o99U66Gxn4FxRilcEk37825DFp9b1C6QlMmdWlDpHPZScDchDY-oHU$ 

Back to the top