patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
	Ray Kinsella <mdr@ashroe.eu>
Cc: Neil Horman <nhorman@tuxdriver.com>,
	Eelco Chaudron <echaudro@redhat.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	David Marchand <david.marchand@redhat.com>,
	"stable@dpdk.org" <stable@dpdk.org>,
	Luca Boccassi <bluca@debian.org>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"Stokes, Ian" <ian.stokes@intel.com>,
	Andrzej Ostruszka <amo@semihalf.com>
Subject: Re: [dpdk-stable] [PATCH v4] meter: provide experimental alias of API for old apps
Date: Mon, 18 May 2020 14:13:50 +0200
Message-ID: <9695064.U7f9L36N0a@thomas> (raw)
In-Reply-To: <2fd78dc9-b63a-6a86-f9f5-ccb40b41118a@ashroe.eu>

18/05/2020 13:48, Ray Kinsella:
> On 18/05/2020 11:46, Thomas Monjalon wrote:
> > 18/05/2020 11:30, Ray Kinsella:
> >> On 18/05/2020 10:22, Thomas Monjalon wrote:
> >>> 18/05/2020 08:29, Ray Kinsella:
> >>>> On 17/05/2020 20:52, Dumitrescu, Cristian wrote:
> >>>>> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> >>>>>>
> >>>>>> On v20.02 some meter APIs have been matured and symbols moved from
> >>>>>> EXPERIMENTAL to DPDK_20.0.1 block.
> >>>>>>
> >>>>>> This can break the applications that were using these mentioned APIs on
> >>>>>> v19.11. Although there is no modification on the APIs and the action is
> >>>>>> positive and matures the APIs, the affect can be negative to
> >>>>>> applications.
> >>>>>>
> >>>>>> Since experimental APIs can change or go away without notice as part of
> >>>>>> contract, to prevent this negative affect that may occur by maturing
> >>>>>> experimental API, a process update already suggested, which enables
> >>>>>> aliasing without forcing it:
> >>>>>> https://patches.dpdk.org/patch/65863/
> >>>>>>
> >>>>>
> >>>>> Personally, I am not convinced this is really needed.
> >>>>>
> >>>>> Are there any users asking for this?
> >>>>
> >>>> As it happens it is all breaking our abi regression test suite.
> >>>> One of the things we do is to run the unit tests binary from v19.11 against the latest release. 
> >>>>  
> >>>>> Is there any other library where this is also applied, or is librte_meter the only library?
> >>>>
> >>>> librte_meter is the only example AFAIK. 
> >>>> But then we only have one example of needing symbol versioning also at the moment (Cryptodev).
> >>>>
> >>>> This is going to happen with experimental symbols that have been around a while, 
> >>>> that have become used in applications. It is a non-mandatory tool a maintainer can use
> >>>> to preserve abi compatibility.
> >>>
> >>> If you want to maintain ABI compatibility of experimental symbols,
> >>> it IS a mandatory tool.
> >>> You cannot enforce your "ABI regression test suite" and at the same time
> >>> say it is "non-mandatory".
> >>>
> >>> The real question here is to know whether we want to maintain compatibility
> >>> of experimental symbols. We said no. Then we said we can.
> >>> The main concern is the message clarity in my opinion.
> >>>
> >>
> >> There is complete clarity, there is no obligation. 
> >> Our lack of obligation around experimental, is upfront in the policy is upfront in the policy.
> >>
> >> "Libraries or APIs marked as experimental may change without constraint, as they are not considered part of an ABI version. Experimental libraries have the major ABI version 0."
> >>
> >> Later we give the _option_ without obligation to add an alias to experimental.pls see the v6.
> >>
> >> +   - In situations in which an ``experimental`` symbol has been stable for some
> >> +     time. When promoting the symbol to become part of the next ABI version, the
> >> +     maintainer may choose to provide an alias to the ``experimental`` tag, so
> >> +     as not to break consuming applications.
> >>
> >> So it is something a Maintainer, _may_ choose to do.
> >> I use the word, "may" not "will" as there is no obligation's associated with experimental.
> > 
> > 
> > OK Ray, this is my understanding as well.
> > 
> > The only difficult part to understand is when claiming
> > "it is all breaking our abi regression test suite"
> > to justify the choice.
> 
> Justification, is the same as any other consumer of DPDK saying you broke my APP.
> 
> > As the maintainer (Cristian) says he does not like this change,
> > it means the regression test suite should skip this case, right?
> 
> So the regression test run the v19.11 Unit Test's against the v20.05 rc.
> My thought was that would provide reasonably good coverage of the ABI to catch more subtly regression.
> Those regressions that affect the behavior of the ABI (the contract), instead of ABI itself. 

I understand the goal.
And I think, because of this goal, you will try to maintain ABI compat
of *ALL* experimental symbols maturing as stable symbol.



  reply	other threads:[~2020-05-18 12:14 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200513121149.2283385-1-ferruh.yigit@intel.com>
2020-05-13 18:05 ` [dpdk-stable] [PATCH v2] " Ferruh Yigit
2020-05-14  8:44   ` Ray Kinsella
2020-05-14 11:53     ` Ferruh Yigit
2020-05-14 11:52 ` [dpdk-stable] [PATCH v3] " Ferruh Yigit
2020-05-14 15:10   ` Ray Kinsella
2020-05-14 15:32   ` David Marchand
2020-05-14 15:56     ` Ray Kinsella
2020-05-14 16:07     ` Ferruh Yigit
2020-05-14 16:30       ` David Marchand
2020-05-14 16:11 ` [dpdk-stable] [PATCH v4] " Ferruh Yigit
2020-05-15 13:31   ` Thomas Monjalon
2020-05-15 14:41     ` Ray Kinsella
2020-05-15 15:03     ` Ray Kinsella
2020-05-15 14:36   ` [dpdk-stable] [dpdk-dev] " Ray Kinsella
2020-05-15 15:01   ` Ray Kinsella
2020-05-17 19:52   ` [dpdk-stable] " Dumitrescu, Cristian
2020-05-18  6:29     ` Ray Kinsella
2020-05-18  9:22       ` Thomas Monjalon
2020-05-18  9:30         ` Ray Kinsella
2020-05-18 10:46           ` Thomas Monjalon
2020-05-18 11:18             ` Dumitrescu, Cristian
2020-05-18 11:49               ` Ray Kinsella
2020-05-18 11:48             ` Ray Kinsella
2020-05-18 12:13               ` Thomas Monjalon [this message]
2020-05-18 13:06                 ` Ray Kinsella
2020-05-18 18:30 ` [dpdk-stable] [PATCH v5] " Ferruh Yigit
2020-05-19 12:16 ` [dpdk-stable] [PATCH v6] " Ferruh Yigit
2020-05-19 13:26   ` Dumitrescu, Cristian
2020-05-19 14:24     ` [dpdk-stable] [dpdk-dev] " Thomas Monjalon
2020-05-19 14:22   ` [dpdk-stable] " Ray Kinsella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9695064.U7f9L36N0a@thomas \
    --to=thomas@monjalon.net \
    --cc=amo@semihalf.com \
    --cc=bluca@debian.org \
    --cc=bruce.richardson@intel.com \
    --cc=cristian.dumitrescu@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=echaudro@redhat.com \
    --cc=ferruh.yigit@intel.com \
    --cc=ian.stokes@intel.com \
    --cc=mdr@ashroe.eu \
    --cc=nhorman@tuxdriver.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

patches for DPDK stable branches

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/stable/0 stable/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 stable stable/ https://inbox.dpdk.org/stable \
		stable@dpdk.org
	public-inbox-index stable

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.stable


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git