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 <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." > >> > > 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.
