* Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
2020-01-16 12:42 ` Ferruh Yigit
@ 2020-01-16 14:38 ` Thomas Monjalon
2020-01-17 8:27 ` David Marchand
2020-01-22 13:55 ` [dpdk-stable] " Ray Kinsella
2020-01-30 16:33 ` Ray Kinsella
2 siblings, 1 reply; 11+ messages in thread
From: Thomas Monjalon @ 2020-01-16 14:38 UTC (permalink / raw)
To: Neil Horman, David Marchand, Ferruh Yigit
Cc: Ray Kinsella, Cristian Dumitrescu, dpdk stable, dev,
Eelco Chaudron, Kevin Traynor, Ian Stokes, Ilya Maximets,
Luca Boccassi
16/01/2020 13:42, Ferruh Yigit:
> On 1/16/2020 11:54 AM, Neil Horman wrote:
> > On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
> >> On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <echaudro@redhat.com> wrote:
> >>>
> >>> Moved RFC4115 APIs to none experimental as they have been there
> >>> since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
> >>>
> >>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> >>
> >> There is a discussion on the OVS ml at the moment to get these symbols
> >> in the stable ABI for 19.11.
> >> I want to understand how this would be done.
> >>
> >> - I take this patch in 20.02, these symbols are added in the 20.0.1 ABI.
> >> On the other hand, the 19.11 release maintains the 20.0 ABI.
> >>
> >> Does it mean the backport adds these symbols with the 20.0 version in
> >> the 19.11 branch?
> >> Or is 20.0.1 version acceptable / a thing we want?
We cannot have the symbol with different versions in different releases,
otherwise the compatibility is broken when upgrading.
So we have no choice, the symbol must have version 20.0.1
in release 19.11.1, as in release 20.02.
> >> - These symbol already existed in the 20.0 ABI, versioned as EXPERIMENTAL.
> >> We can go and remove these entries since we are not bound to preserve
> >> the experimental APIs.
> >> But, on the other hand, nothing should prevent us from keeping some
> >> aliases so that the symbols versioned EXPERIMENTAL are still available
> >> to existing users.
> >>
> > I would say that choice is up to you. If you want to alias them to be nice to
> > prior users, thats fine by me. But experimental means experimental, and so users
> > have to be prepared to rebuild when things change, even if that change is
> > changing the version from experimental to a concrete version.
> >
>
> I would prefer to keep the alias and don't break the existing users, specially
> for the case experimental API is becoming mature without change.
I agree, it's cool to be nice :)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
2020-01-16 14:38 ` Thomas Monjalon
@ 2020-01-17 8:27 ` David Marchand
2020-01-17 10:46 ` [dpdk-stable] [dpdk-dev] " Luca Boccassi
0 siblings, 1 reply; 11+ messages in thread
From: David Marchand @ 2020-01-17 8:27 UTC (permalink / raw)
To: Thomas Monjalon, Luca Boccassi
Cc: Neil Horman, Ferruh Yigit, Ray Kinsella, Cristian Dumitrescu,
dpdk stable, dev, Eelco Chaudron, Kevin Traynor, Ian Stokes,
Ilya Maximets
On Thu, Jan 16, 2020 at 3:38 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 16/01/2020 13:42, Ferruh Yigit:
> > On 1/16/2020 11:54 AM, Neil Horman wrote:
> > > On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
> > >> On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <echaudro@redhat.com> wrote:
> > >>>
> > >>> Moved RFC4115 APIs to none experimental as they have been there
> > >>> since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
> > >>>
> > >>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> > >>
> > >> There is a discussion on the OVS ml at the moment to get these symbols
> > >> in the stable ABI for 19.11.
> > >> I want to understand how this would be done.
> > >>
> > >> - I take this patch in 20.02, these symbols are added in the 20.0.1 ABI.
> > >> On the other hand, the 19.11 release maintains the 20.0 ABI.
> > >>
> > >> Does it mean the backport adds these symbols with the 20.0 version in
> > >> the 19.11 branch?
> > >> Or is 20.0.1 version acceptable / a thing we want?
>
> We cannot have the symbol with different versions in different releases,
> otherwise the compatibility is broken when upgrading.
> So we have no choice, the symbol must have version 20.0.1
> in release 19.11.1, as in release 20.02.
Indeed, good point.
> > >> - These symbol already existed in the 20.0 ABI, versioned as EXPERIMENTAL.
> > >> We can go and remove these entries since we are not bound to preserve
> > >> the experimental APIs.
> > >> But, on the other hand, nothing should prevent us from keeping some
> > >> aliases so that the symbols versioned EXPERIMENTAL are still available
> > >> to existing users.
> > >>
> > > I would say that choice is up to you. If you want to alias them to be nice to
> > > prior users, thats fine by me. But experimental means experimental, and so users
> > > have to be prepared to rebuild when things change, even if that change is
> > > changing the version from experimental to a concrete version.
> > >
> >
> > I would prefer to keep the alias and don't break the existing users, specially
> > for the case experimental API is becoming mature without change.
>
> I agree, it's cool to be nice :)
Luca, opinion?
--
David Marchand
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-stable] [dpdk-dev] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
2020-01-17 8:27 ` David Marchand
@ 2020-01-17 10:46 ` Luca Boccassi
0 siblings, 0 replies; 11+ messages in thread
From: Luca Boccassi @ 2020-01-17 10:46 UTC (permalink / raw)
To: David Marchand, Thomas Monjalon
Cc: Neil Horman, Ferruh Yigit, Ray Kinsella, Cristian Dumitrescu,
dpdk stable, dev, Eelco Chaudron, Kevin Traynor, Ian Stokes,
Ilya Maximets
On Fri, 2020-01-17 at 09:27 +0100, David Marchand wrote:
> On Thu, Jan 16, 2020 at 3:38 PM Thomas Monjalon <
> thomas@monjalon.net
> > wrote:
> > 16/01/2020 13:42, Ferruh Yigit:
> > > On 1/16/2020 11:54 AM, Neil Horman wrote:
> > > > On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
> > > > > On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <
> > > > > echaudro@redhat.com
> > > > > > wrote:
> > > > > > Moved RFC4115 APIs to none experimental as they have been
> > > > > > there
> > > > > > since 19.02. Also, these APIs are the same as the none
> > > > > > RFC4115 APIs.
> > > > > >
> > > > > > Signed-off-by: Eelco Chaudron <
> > > > > > echaudro@redhat.com
> > > > > > >
> > > > >
> > > > > There is a discussion on the OVS ml at the moment to get
> > > > > these symbols
> > > > > in the stable ABI for 19.11.
> > > > > I want to understand how this would be done.
> > > > >
> > > > > - I take this patch in 20.02, these symbols are added in the
> > > > > 20.0.1 ABI.
> > > > > On the other hand, the 19.11 release maintains the 20.0 ABI.
> > > > >
> > > > > Does it mean the backport adds these symbols with the 20.0
> > > > > version in
> > > > > the 19.11 branch?
> > > > > Or is 20.0.1 version acceptable / a thing we want?
> >
> > We cannot have the symbol with different versions in different
> > releases,
> > otherwise the compatibility is broken when upgrading.
> > So we have no choice, the symbol must have version 20.0.1
> > in release 19.11.1, as in release 20.02.
>
> Indeed, good point.
>
>
> > > > > - These symbol already existed in the 20.0 ABI, versioned as
> > > > > EXPERIMENTAL.
> > > > > We can go and remove these entries since we are not bound to
> > > > > preserve
> > > > > the experimental APIs.
> > > > > But, on the other hand, nothing should prevent us from
> > > > > keeping some
> > > > > aliases so that the symbols versioned EXPERIMENTAL are still
> > > > > available
> > > > > to existing users.
> > > > >
> > > >
> > > > I would say that choice is up to you. If you want to alias
> > > > them to be nice to
> > > > prior users, thats fine by me. But experimental means
> > > > experimental, and so users
> > > > have to be prepared to rebuild when things change, even if that
> > > > change is
> > > > changing the version from experimental to a concrete version.
> > > >
> > >
> > > I would prefer to keep the alias and don't break the existing
> > > users, specially
> > > for the case experimental API is becoming mature without change.
> >
> > I agree, it's cool to be nice :)
>
> Luca, opinion?
I'd not only prefer it but also go as far as require it for backporting
to 19.11 - experimental means experimental, but stable means stable :-)
--
Kind regards,
Luca Boccassi
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
2020-01-16 12:42 ` Ferruh Yigit
2020-01-16 14:38 ` Thomas Monjalon
@ 2020-01-22 13:55 ` Ray Kinsella
2020-01-30 16:33 ` Ray Kinsella
2 siblings, 0 replies; 11+ messages in thread
From: Ray Kinsella @ 2020-01-22 13:55 UTC (permalink / raw)
To: Ferruh Yigit, Neil Horman, David Marchand
Cc: Thomas Monjalon, Cristian Dumitrescu, dpdk stable, dev,
Eelco Chaudron, Kevin Traynor, Ian Stokes, Ilya Maximets,
Luca Boccassi
On 16/01/2020 12:42, Ferruh Yigit wrote:
> On 1/16/2020 11:54 AM, Neil Horman wrote:
>> On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
>>> On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <echaudro@redhat.com> wrote:
>>>>
>>>> Moved RFC4115 APIs to none experimental as they have been there
>>>> since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
>>>>
>>>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
>>>
>>> There is a discussion on the OVS ml at the moment to get these symbols
>>> in the stable ABI for 19.11.
>>> I want to understand how this would be done.
>>>
>>> - I take this patch in 20.02, these symbols are added in the 20.0.1 ABI.
>>> On the other hand, the 19.11 release maintains the 20.0 ABI.
>>>
>>> Does it mean the backport adds these symbols with the 20.0 version in
>>> the 19.11 branch?
>>> Or is 20.0.1 version acceptable / a thing we want?
>>>
>>>
>>> - These symbol already existed in the 20.0 ABI, versioned as EXPERIMENTAL.
>>> We can go and remove these entries since we are not bound to preserve
>>> the experimental APIs.
>>> But, on the other hand, nothing should prevent us from keeping some
>>> aliases so that the symbols versioned EXPERIMENTAL are still available
>>> to existing users.
>>>
>> I would say that choice is up to you. If you want to alias them to be nice to
>> prior users, thats fine by me. But experimental means experimental, and so users
>> have to be prepared to rebuild when things change, even if that change is
>> changing the version from experimental to a concrete version.
>>
>
> I would prefer to keep the alias and don't break the existing users, specially
> for the case experimental API is becoming mature without change.
>
+1 keeping an alias until 20.11/v21 is a good idea, particularly if the API is "baked"
and has not changed in some time - as is the case here.
Ray K
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental
2020-01-16 12:42 ` Ferruh Yigit
2020-01-16 14:38 ` Thomas Monjalon
2020-01-22 13:55 ` [dpdk-stable] " Ray Kinsella
@ 2020-01-30 16:33 ` Ray Kinsella
2 siblings, 0 replies; 11+ messages in thread
From: Ray Kinsella @ 2020-01-30 16:33 UTC (permalink / raw)
To: Ferruh Yigit, Neil Horman, David Marchand
Cc: Thomas Monjalon, Cristian Dumitrescu, dpdk stable, dev,
Eelco Chaudron, Kevin Traynor, Ian Stokes, Ilya Maximets,
Luca Boccassi
On 16/01/2020 12:42, Ferruh Yigit wrote:
> On 1/16/2020 11:54 AM, Neil Horman wrote:
>> On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
>>> On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <echaudro@redhat.com> wrote:
>>>>
>>>> Moved RFC4115 APIs to none experimental as they have been there
>>>> since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
>>>>
>>>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
>>>
>>> There is a discussion on the OVS ml at the moment to get these symbols
>>> in the stable ABI for 19.11.
>>> I want to understand how this would be done.
>>>
>>> - I take this patch in 20.02, these symbols are added in the 20.0.1 ABI.
>>> On the other hand, the 19.11 release maintains the 20.0 ABI.
>>>
>>> Does it mean the backport adds these symbols with the 20.0 version in
>>> the 19.11 branch?
>>> Or is 20.0.1 version acceptable / a thing we want?
>>>
>>>
>>> - These symbol already existed in the 20.0 ABI, versioned as EXPERIMENTAL.
>>> We can go and remove these entries since we are not bound to preserve
>>> the experimental APIs.
>>> But, on the other hand, nothing should prevent us from keeping some
>>> aliases so that the symbols versioned EXPERIMENTAL are still available
>>> to existing users.
>>>
>> I would say that choice is up to you. If you want to alias them to be nice to
>> prior users, thats fine by me. But experimental means experimental, and so users
>> have to be prepared to rebuild when things change, even if that change is
>> changing the version from experimental to a concrete version.
>>
>
> I would prefer to keep the alias and don't break the existing users, specially
> for the case experimental API is becoming mature without change.
>
Apologies for dragging up an older thread.
I had a thought later that we should add something formal to the ABI Policy.
Such that if we have an API that has been part of DPDK as experimental for a long time,
to the point it has a number of users - out of kindness, the maintainer may ask a
contributor to add an alias until the next major ABI version is declared?
So as not to break consuming projects - make sense?
Thanks,
Ray K
^ permalink raw reply [flat|nested] 11+ messages in thread