Without a statement that speaks to derivative works not being qualified as being on a ballot, I cannot see that we have a basis for not approving the CCR for the ballot as long as it meets all other criteria.
I don't think there is anything in our process that is written
down and speaks to the sentiment that's written here. If we want
to provide some process description enhancements that speak to the
issues written below, we can but I would recommend we include this
submission.
-- Ed
On 5/3/2021 7:13 AM, David Blevins
wrote:
I think you may have read my email as advocating for them to be
included. It's definitely not the case.
I suspect that they'll have a hard time finding
someone who will approve now. If that turns out to be the case,
it basically means none of us thought it was of enough value to
include in the release, but no one is the "bad guy" who blocked
them. Sort of like in a very large corporation if you need
permission, you might not ever find someone who will say no to
your idea and engage you in a political fight, but you're also
unlikely to find someone to say yes.
Yes,
David. We
have a low bar for being a compatible product.
Someone marks it as
Accepted and they are in as a Compatible
Implementation.
But, the question
here is where to include a GF derivative as a CI for
ratification. Several
teams have put in a ton of effort to ensure their
products are Compatible
with 9.1 and to be included on the ballot (GF, OL, WF,
and now TomEE).
Is it fair to these projects to allow a GF derivative
(with no added
feature or function) to be included on the ballot?
Yes, they ran
the TCK. And, they definitely qualify as a Compatible
Product. But,
do they qualify for being included for ratification
and the ballot? That's
the question.
---------------------------------------------------
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)
I think that
criteria for getting on
the ballot should be someone from the platform project
(or respective spec
project) has marked the certification request
accepted.
As the entity
casting the ballot, I definitely
don't want to 1) be solely deciding who does or does
not get on the ballot
or 2) be perceived as blocking someone. If some one
feels the CCR
is acceptable they can approve and do not need to
convince anyone. That's
a pretty low bar and if no one is willing to cross it,
then that's that.
Hi,
Some of you may have noticed that ManagedCat has
submitted their ManagedFish
product as a CI for Ratification:
Hi Kevin
Can you also put ManageCat into the ballot as we
opened a 9.1 certification
request in https://github.com/eclipse-ee4j/jakartaee-platform/issues/350
Regards.
Gurkan
I have posted my thoughts on this request both to his
CCR (https://github.com/eclipse-ee4j/jakartaee-platform/issues/350)
and the Specifications PR (https://github.com/jakartaee/specifications/pull/372).
I basically indicated that I didn't see a need to
list ManagedCat
as a CI for Ratification and include it on the ballot
because it's basically
just a commercially supported version of Eclipse
Glassfish. I welcomed
him to submit his product for the Compatible Products
page.
Gurkan does not agree and is asking to be included on
the ballot. This
is a unique case that is not directly outlined in the
EFSP. What
are the collective thoughts from the Spec Committee?
We want to get
this ballot out today, so an immediate discussion is
required. Thanks!
---------------------------------------------------
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