| Re: [jakarta.ee-spec] [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
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.
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.
On Feb 10, 2021, at 2:35 PM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
David,
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)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
From: David Blevins <dblevins@xxxxxxxxxxxxx>
To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Date: 02/10/2021 13:12
Subject: [EXTERNAL] [jakarta.ee-spec] Ratified Implementations and special designation in the eyes of users
Sent by: "jakarta.ee-spec" <jakarta.ee-spec-bounces@xxxxxxxxxxx>
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 jakarta.ee-spec 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.
Thoughts?
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852
_______________________________________________
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
_______________________________________________ jakarta.ee-spec mailing list jakarta.ee-spec@xxxxxxxxxxx To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec__;!!GqivPVa7Brio!Jim_p6_C9o99U66Gxn4FxRilcEk37825DFp9b1C6QlMmdWlDpHPZScDchDY-oHU$