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 <tho...@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.si...@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."
then,
"The promotion or removal of symbols will typically form part of a conversation
between the maintainer and the original contributor.".
As I said, in my email above ...
"Maturing of any ABI/API is a conversation between a maintainer and the
contributor.
If they strongly feel, it is a pointless exercise [to make the symbols stable]
- I won't argue.
Or to be _abundantly clear_ ...
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.
Ray K
