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

["Kinsella, Ray" <mdr@ashroe.eu>]

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?

Ray K