[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] Fair rules for "optional" TCK compliance tests (was: Inconsistency on the term "pruned")
|
Thanks for raising
this issue, David. This "required" Optional aspects of
the Specifications will forever tie us to Glassfish. And, like you
said, that's not fair to the Glassfish team or the other Compatible Implementations.I like the idea
of creating "extensions" or "standalone" specifications
for the optional pieces. This would allow many alternatives for verifying
the final "core" Specification instead of relying just on Glassfish.
It would also allow various timelines for accomplishing the task
for verifying these "extensions". That is, we wouldn't
be tied to it for the "GA release" of Jakarta EE x.Question: Would
we actually consider this for Jakarta EE 9? Personally, I think we're
too far down the pike to change course for 9, but this sounds like an excellent
idea to kick off with Jakarta EE 10.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutterFrom:
"Kevin
Sutter" <sutter@xxxxxxxxxx>To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>Date:
07/02/2020
09:01Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] Fair rules for "optional" TCK compliance
tests (was: Inconsistency on the term "pruned")Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
Correct. Removed
features can continue to be shipped and packaged with a compliant app server.
The TCK from the past release would still need to be executed and
passed for these removed features.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Gurkan
Erdogdu <cgurkanerdogdu@xxxxxxxxx>
To: jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 07/02/2020
08:31
Subject: [EXTERNAL]
Re: [jakartaee-platform-dev] Fair rules for "optional" TCK compliance
tests (was: Inconsistency on the term "pruned")
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
I
thought we did away with the restriction that removed features cannot be
shipped
IMHO, you can ship but when you ship, you need the pass the related TCK
suite
On Thu, Jul 2, 2020 at 4:23 PM Scott Stark <starksm64@xxxxxxxxx>
wrote:
I thought we did away with the restriction that removed features cannot
be shipped. I certainly made that comment on the EE 9 platform spec when
that showed up. This is the crux of the problem. We need to be more aggressive
at removing features and have no restriction on vendors that want to support
legacy spec features.
On Wed, Jul 1, 2020 at 7:52 PM David Blevins <dblevins@xxxxxxxxxxxxx>
wrote:>
On May 22, 2020, at 1:20 PM, David Blevins <dblevins@xxxxxxxxxxxxx>
wrote:
>
> Unless we fix that last bullet everything will stay in optional status
and we'll create a situation that is in practice competitively unfair to
GlassFish.
I'd like to start a thread which does not need to complete now, but I think
would be good to get going.
In our 'Inconsistency on the term "pruned"' thread I raised the
point that our current TCK rules around optional are competitively unfair
to GlassFish.
The rules we have now state that one implementation must implement all
optional parts of a specification before that specification and TCK go
final. To understand why this is an incredible disadvantage let's
talk about how optional features come into our lives and why they are so
hard to remove.
It's very common that an implementation has an innovation that is very
popular with their users and gains some limited traction with other implementations.
That feature often finds its way into a specification as a standard
requirement. Over time sometimes that idea never catches on with
other user bases or loses favor to better techniques in the industry. In
that situation, however, the original user base tied to the implementation
that founded the idea will still be there, only now dependent on the standard
interfaces.
This puts us in a catch 22.
- If we remove the feature, that means per the current rules it cannot
be shipped by anyone. This damages the user base of the implementation
that innovated the idea basically saying to them, "The users of other
vendors didn't find the feature you critically need to be as useful as
you do, so now you can't use it anymore."
- If we mark it optional, that means per current rules one implementation
must implement it and all other optional ideas. This damages that
implementation as they're basically in the position to have to implement
everyone's failed ideas. Being the industry's technical debt collector
is not competitively fair and only gets worse with time.
So what do we do?
Down one path we nuke and entire implementation and their oldest users.
Down the other path we bog and implementation down with technical
debt they can't reasonably pay for as they don't have the users that need
it.
Neither are good options and I suggest the only fair and just solution
is we find a way to shift the debt to the implementation that not only
can pay it, but needs it to survive.
Here are two ways we could solve that. While not sexy, they are potentially
better than the consequences above:
- Require "a sufficient number of compatible implementations"
to prove all optional tests. Meaning, we may need more than one compatible
implementation to be present for a specification to go final. The
Pizza specification requires Cheese and has options for Pepperoni, Onions
and Pinneapple. Joe's implementation has Onion and Peperoni. Jane's
implementation has Pepperoni and Pineapple. Between the two of them
all requirements are met and we reasonable know all parts of the TCK can
be passed. Until both show up, however, the specification and TCK
cannot be released.
- Split optional tests into their own spec/tck that can be implemented
and released later. We see over time Willy is the only implementation
shipping Pineapple and is not keeping up. We split out the Pineapple
tests into its own specification/tck and it sits there till Willy is able
to pass it. From the Pizza Platform perspective it is not optional
or removed, it simply has reverted back to being a standalone specification
with no connection to the Platform.
I suggest there is no universal decision we need to make between A or B.
In some situations we may chose A, in others B. We may in fact
find ourselves in the patter where we try A for a while and revert to B
if we see impact on our timelines.
Thoughts?
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev