Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API

[Thomas Monjalon <thomas@monjalon.net>]

13/10/2021 13:42, Kinsella, Ray:
> On 13/10/2021 12:11, Bruce Richardson wrote:
> > On Wed, Oct 13, 2021 at 11:02:02AM +0100, Kinsella, Ray wrote:
> >> On 13/10/2021 10:49, Thomas Monjalon wrote:
> >>> 13/10/2021 11:43, Kinsella, Ray:
> >>>> On 13/10/2021 10:40, Thomas Monjalon wrote:
> >>>>> 13/10/2021 10:51, Kinsella, Ray:
> >>>>>> On 12/10/2021 22:52, Thomas Monjalon wrote:
> >>>>>>> 12/10/2021 22:34, Dumitrescu, Cristian:
> >>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>>>>> 01/09/2021 14:20, Jasvinder Singh:
> >>>>>>>>>> These APIs were introduced in 18.05, therefore removing
> >>>>>>>>>> experimental tag to promote them to stable state.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> >>>>>>>>>> ---
> >>>>>>>>>>  lib/pipeline/rte_port_in_action.h | 10 ----------
> >>>>>>>>>>  lib/pipeline/rte_table_action.h   | 18 ------------------
> >>>>>>>>>>  lib/pipeline/version.map          | 16 ++++++----------
> >>>>>>>>>>  3 files changed, 6 insertions(+), 38 deletions(-)
> >>>>>>>>>
> >>>>>>>>> Cristian, please can you check whether you intend to keep these functions in
> >>>>>>>>> future?
> >>>>>>>>> If they are candidate to be removed, there is no point to promote them.
> >>>>>>>>
> >>>>>>>> Hi Thomas,
> >>>>>>>>
> >>>>>>>> Yes, they are candidate for removal, as the new rte_swx_pipeline API evolves.
> >>>>>>>>
> >>>>>>>> But removing them requires updating the drivers/net/softnic code to use the new API, which is not going to be completed in time for release 21.11.
> >>>>>>>>
> >>>>>>>> So given this lag, it might be better to simply promote these functions to stable API now, as Ray suggests, instead of continuing to keep them experimental; then, once these functions are no longer used, then we can remove them, most likely in 22.11.
> >>>>>>>>
> >>>>>>>> So I will ack these patches, but I am willing to reconsider if you feel strongly against this approach.
> >>>>>>>
> >>>>>>> I think we should not promote API that we know will disappear soon.
> >>>>>>> The stable status means something for the users.
> >>>>>>> Ray, what is your opinion?
> >>>>>>>
> >>>>>>
> >>>>>> Well - I agree with Cristian (he and I discuss this a few weeks ago).
> >>>>>> My position is if you are going to maintain an API, that means giving a few guarantees.
> >>>>>> The API's have been experimental for 3 years ... at what point do they mature?
> >>>>>>
> >>>>>> However, I agree there is two ways to look at this thing, I try to be pragmatic. 
> >>>>>> Maturing of any ABI/API is a conversation between a maintainer and the contributor.
> >>>>>> If they strongly feel, it is a pointless exercise - I won't argue. 
> >>>>>
> >>>>> I think you did't get it.
> >>>>> This API will be removed soon.
> >>>>> That's why I think it doesn't make sense to make them stable, just before removing.
> >>>>>
> >>>>
> >>>> Nope, I got it 110%
> >>>> I reflected both my opinion as ABI Maintainer, and tried to be pragmatic about the situation.
> >>>>
> >>>> As I said "Maturing of any ABI/API is a conversation between a maintainer and the contributor.
> >>>> If they strongly feel, it is a pointless exercise - I won't argue."
> >>>
> >>> Sorry, I don't understand your position.
> >>> Do you think we should promote functions to stable which are candidate to be removed soon?
> >>>
> >>
> >> I am just reflecting the policy here.
> >>
> >> "An API’s experimental status should be reviewed annually, by both the maintainer and/or the original contributor. Ordinarily APIs marked as experimental will be promoted to the stable ABI once a maintainer has become satisfied that the API is mature and is unlikely to change."
> >>
> > If an API is planned for removal, then I think it falls under the bucket of
> > "likely to change", so should not be made non-experimental. Therefore I'd
> > agree with Thomas view on this - not so much that promoting them is
> > pointless, but I'd actually view it as harmful in encouraging use that will
> > be broken in future.
> > 
> 
> To be clear (again).
> 
> I don't think we should promote functions needlessly, as I said, if others decide it is pointless, I won't argue.  
> I do think if we have a policy, that experimental symbols will mature or be removed, we should be careful about the exceptions we make, lest the policy becomes irrelevant and ignored. 
> 
> Since we have argued this out, endlessly ... we can agree, we have been careful about this exception and move on?

The patch is set as rejected.