Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)

[Romain Manni-Bucau]

Right, because the issue is not people having migrated but people migrating
when jakarta releases are available so think you are right, it covers
something like 0 user ;)

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 25 mai 2022 à 09:56, Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> a écrit :

> Hi,
>
> JL wrote "Meanwhile, I'd create an issue on the TCK + Spec" in another
> mail and as I want to learn something about the involved workflows /
> processes (sorry - never had to deal with it):
>
> - What would we need to do to challenge the TCK + Spec in this regard?
> - Who can do this - I assume it is vendor-driven, so PMC?
> - Is it something super time consuming?
> - Is it opening an issue and writing some elaborated text explaining
> the situation / unclarity?
>
> I guess, that the user community who already migrated to jakarta.*
> isn't that big at the moment (my assumption), so perhaps there is
> enought time to open a challenge and clarify the situation. If users
> complain, we can go still do a "bug" fix release?
>
> Gruß
> Richard
>
>
>
> Am Mittwoch, dem 25.05.2022 um 09:03 +0200 schrieb Romain Manni-Bucau:
> > Hi
> >
> > The small notes on that are:
> >
> > - rare impl actually do (asf ones but also other vendors), it is
> > always a compromise between users/customers/consumers and specs
> > - there is always a blurry line on some defaults (trivial example is
> > default impl or provider impl even when defined in spec)
> > - another blurry line is for libs vs distros
> >
> > So overall we are still free to choose in most cases even if we
> > should tend to what you described.
> >
> > Side note: I dont want to emphasize the disrespect of that rule but
> > the fact *we* must choose at the end.
> >
> >
> > Le mer. 25 mai 2022 à 03:20, David Blevins 
> > a écrit :
> > > > On May 24, 2022, at 6:14 PM, David Blevins <
> > > david.blev...@gmail.com> wrote:
> > > >
> > > > You could have flags that enabled non-compliant behavior, but
> > > they would have to be off by default and require user action to
> > > turn them on.
> > >
> > > To be clear I could have used a better word than "flags."  You can
> > > have any means you like to enable non-compliant behavior such as
> > > annotations, alternate jars, etc.  Anything that must be done
> > > explicitly by a user to put themselves knowingly in a non-compliant
> > > state.
> > >
> > >
> > > -David
> > >
>

Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)

[Zowalla, Richard]

Hi,

JL wrote "Meanwhile, I'd create an issue on the TCK + Spec" in another
mail and as I want to learn something about the involved workflows /
processes (sorry - never had to deal with it):

- What would we need to do to challenge the TCK + Spec in this regard?
- Who can do this - I assume it is vendor-driven, so PMC?
- Is it something super time consuming? 
- Is it opening an issue and writing some elaborated text explaining
the situation / unclarity?

I guess, that the user community who already migrated to jakarta.*
isn't that big at the moment (my assumption), so perhaps there is
enought time to open a challenge and clarify the situation. If users
complain, we can go still do a "bug" fix release?

Gruß
Richard



Am Mittwoch, dem 25.05.2022 um 09:03 +0200 schrieb Romain Manni-Bucau:
> Hi
> 
> The small notes on that are:
> 
> - rare impl actually do (asf ones but also other vendors), it is
> always a compromise between users/customers/consumers and specs
> - there is always a blurry line on some defaults (trivial example is
> default impl or provider impl even when defined in spec)
> - another blurry line is for libs vs distros
> 
> So overall we are still free to choose in most cases even if we
> should tend to what you described.
> 
> Side note: I dont want to emphasize the disrespect of that rule but
> the fact *we* must choose at the end.
> 
> 
> Le mer. 25 mai 2022 à 03:20, David Blevins 
> a écrit :
> > > On May 24, 2022, at 6:14 PM, David Blevins <
> > david.blev...@gmail.com> wrote:
> > > 
> > > You could have flags that enabled non-compliant behavior, but
> > they would have to be off by default and require user action to
> > turn them on.
> > 
> > To be clear I could have used a better word than "flags."  You can
> > have any means you like to enable non-compliant behavior such as
> > annotations, alternate jars, etc.  Anything that must be done
> > explicitly by a user to put themselves knowingly in a non-compliant 
> > state.
> > 
> > 
> > -David
> > 


smime.p7s
Description: S/MIME cryptographic signature

Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)

[Romain Manni-Bucau]

Hi

The small notes on that are:

- rare impl actually do (asf ones but also other vendors), it is always a
compromise between users/customers/consumers and specs
- there is always a blurry line on some defaults (trivial example is
default impl or provider impl even when defined in spec)
- another blurry line is for libs vs distros

So overall we are still free to choose in most cases even if we should tend
to what you described.

Side note: I dont want to emphasize the disrespect of that rule but the
fact *we* must choose at the end.


Le mer. 25 mai 2022 à 03:20, David Blevins  a
écrit :

> > On May 24, 2022, at 6:14 PM, David Blevins 
> wrote:
> >
> > You could have flags that enabled non-compliant behavior, but they would
> have to be off by default and require user action to turn them on.
>
> To be clear I could have used a better word than "flags."  You can have
> any means you like to enable non-compliant behavior such as annotations,
> alternate jars, etc.  Anything that must be done explicitly by a user to
> put themselves knowingly in a non-compliant state.
>
>
> -David
>
>

Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)

[David Blevins]

> On May 24, 2022, at 6:14 PM, David Blevins  wrote:
> 
> You could have flags that enabled non-compliant behavior, but they would have 
> to be off by default and require user action to turn them on.

To be clear I could have used a better word than "flags."  You can have any 
means you like to enable non-compliant behavior such as annotations, alternate 
jars, etc.  Anything that must be done explicitly by a user to put themselves 
knowingly in a non-compliant state.


-David



smime.p7s
Description: S/MIME cryptographic signature

Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)

[David Blevins]

Just wanted to echo what Jean-Louis said and add some details.

During the 20 years of these specs living in the JCP, the license requirements 
stated that you must agree to ship your implementation with all defaults set to 
the compliant state.  You could have flags that enabled non-compliant behavior, 
but they would have to be off by default and require user action to turn them 
on.

If we encounter a situation where we don't pass a test, here are the valid 
outcomes:

 1.  We decide to change our default behavior so we can pass the test.
 We may chose to create a way to enable the previous behavior, but
 we do not work that way by default.

 2.  We decide we think our behavior is spec-compliant and the TCK is
 testing something not defined by or against the spec.  We file a
 TCK challenge.

 A. Our challenge is approved.  We can ignore that failure and
still claim compliance.
 
 B. Our challenge is rejected.

i.  We execute option #1 and ship a compliant implementation.

ii. We decide we don't care about compliance.  Our users may
disagree and may need to patch or fork.


-David



> On May 24, 2022, at 5:12 PM, Jean-Louis MONTEIRO  wrote:
> 
> I always find it better when we can keep backward compatibility for users.
> But this is a major version and I'm not a big fan of cheap system properties.
> 
> If we think it's not good, we should create a challenge to get it fixed in 
> the spec + TCK.
> Otherwise, I would keep it the way it is. If it breaks users and we want to 
> help them out, it's still time to add the system property or a better 
> configuration option and do a maintenance release.
> 
> I'd go lazy instead of eager considering it's a major version.
> Meanwhile, I'd create an issue on the TCK + Spec
> 
> 
> Le mar. 24 mai 2022 à 13:21, Zowalla, Richard 
>  a écrit :
> Romain mentioned the idea (via Slack) of introducing a (cheap) system
> property, which a user can specifiy to get back the old behaviour. 
> 
> If we want to follow the compatibility appraoch, we should add that
> flag as the spec / RI is really unclear.
> 
> 
> Am Dienstag, dem 24.05.2022 um 13:01 +0200 schrieb Romain Manni-Bucau:
> > I conclude the same thing thanks your pointers so back to the
> > question: do we want to maintain the compat for our user base, do we
> > want to align on the random spec behavior or do we don't care?
> > Indeed I'm always in first team, in particular there since it will be
> > deprecated so the least we touch the best it is but guess it is a 50-
> > 50 case in terms of actual points :s.
> > 
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > 
> > 
> > Le mar. 24 mai 2022 à 12:57, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> a écrit :
> > > The test in question is 
> > > https://github.com/eclipse-ee4j/jaf-tck/blob/2.0.1/tests/api/javasoft/sqe/tests/jakarta/activation/ActivationDataFlavor/normalizeMimeTypeParameter_Test.java
> > > 
> > > which expects the plain parameter value instead of
> > > "parameter=value" as
> > > a return value.
> > > 
> > > The JavaDoc is also not quite clear about it:
> > > 
> > > https://jakarta.ee/specifications/activation/2.0/apidocs/jakarta.activation/jakarta/activation/activationdataflavor#normalizeMimeTypeParameter(java.lang.String,java.lang.String)
> > > 
> > > with "This method is called for each parameter name/value pair and
> > > should return the normalized representation of the
> > > parameterValue.".
> > > 
> > > The spec document itself 
> > > https://jakarta.ee/specifications/activation/2.0/jakarta-activation-spec-2.0.html
> > >  doesn't mention anything about it.
> > > 
> > > Guess it is a relict from java.awt.DataFlavour (also @Deprecated
> > > there)
> > > to keep compatibility after removing the references to it.
> > > 
> > > Am Dienstag, dem 24.05.2022 um 12:42 +0200 schrieb Romain Manni-
> > > Bucau:
> > > > Hmm, before that the question is "are the TCK spec compliant", a
> > > lot
> > > > have a reference in the spec we maybe missed, do you have some
> > > > pointers on them? If we were wrong let's fix it, if the TCK are
> > > wrong
> > > > then maybe ignore the TCK?
> > > > 
> > > > Romain Manni-Bucau
> > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > > 
> > > > 
> > > > Le mar. 24 mai 2022 à 12:33, Zowalla, Richard <
> > > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > > There is a TCK test regarding normalizeMimeTypeParameter which
> > > > > broke with the current impl of normalizeMimeTypeParameter 
> > > > > 
> > > > > Therefore, I adjusted it but agree that it is mit really
> > > specified.
> > > > > Question would be, if it is "ok" to fail specific tests of the
> > > TCK.
> > > > > 
> > > > > Gruß
> > > > > Richard
> > > > > Von: Romain Manni-Bucau 
> > > > > Gesendet: Dienstag, 24. Mai 2022 11:53:37
> > > > > An: dev@geronimo.apache.org
> > > > > Betreff: Re: [VOTE] Geronimo activation_2.0_spec