[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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
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
310-633-3852
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
310-633-3852
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$