From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 79D26A0546; Fri, 14 Feb 2020 03:41:02 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7F5381D9E; Fri, 14 Feb 2020 03:41:01 +0100 (CET) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id F371A374 for ; Fri, 14 Feb 2020 03:40:58 +0100 (CET) Received: from [107.15.85.130] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1j2QuC-0004vb-3v; Thu, 13 Feb 2020 21:40:43 -0500 Date: Thu, 13 Feb 2020 21:40:40 -0500 From: Neil Horman To: Ray Kinsella Cc: Luca Boccassi , Ferruh Yigit , Cristian Dumitrescu , Eelco Chaudron , dev@dpdk.org, Thomas Monjalon , David Marchand , Bruce Richardson , Ian Stokes Message-ID: <20200214023820.ogc2neraxwwtolde@penguin.lxd> References: <20200129122953.2016199-1-ferruh.yigit@intel.com> <20200202185334.GA6783@localhost.localdomain> <7beadbbd-bf0d-e545-d9bb-0e3ae8228b71@intel.com> <20200204120230.GA13754@hmswarspite.think-freely.org> <8eaaec5dedcfcf09ae69b15cc80ac1ff1a1f4a30.camel@debian.org> <20200205113245.GA17468@hmswarspite.think-freely.org> <20c7c2a7-54f7-996f-923a-82202ebc66eb@ashroe.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20c7c2a7-54f7-996f-923a-82202ebc66eb@ashroe.eu> User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [RFC] meter: fix ABI break due to experimental tag removal X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Feb 13, 2020 at 05:40:43PM +0000, Ray Kinsella wrote: > > > On 05/02/2020 11:32, Neil Horman wrote: > > On Wed, Feb 05, 2020 at 11:04:29AM +0100, Luca Boccassi wrote: > >> On Tue, 2020-02-04 at 07:02 -0500, Neil Horman wrote: > >>>> But if we can do the versioning in the master, LTS can backport it > >>>> and can have > >>>> mature version of that API in LTS without breaking the existing > >>>> users. > >>>> > >>> > >>> But why bother? The only thing you've changed is the version > >>> tagging. Its ok > >>> to leave that alone in LTS, you just cant change it. > >>> > >>> Thats part of the burden of an LTS release, it will have some drift > >>> from the > >>> upstream head, because you have to keep things stable. So you > >>> stabilize the > >>> upstream ABI version for this API and just never backport it to the > >>> current LTS > >>> release. > >> > >> Hi, > >> > >> A customer (OVS) explicitly and specifically requested backporting the > >> symbol change to 19.11, as they don't want to enable experimental APIs > >> in their releases. I replied that it would only be acceptable with > >> aliasing to keep compatibility, and Ferruh very kindly did the work to > >> implement that. > >> > > but, thats part of the agreement, no? You can't always have new features and > > stability at the same time. > > > > I get that this is an odd corner case, because strictly speaking you could waive > > the ABI change that libabigail is reporting, and most application users (like > > OVS) could get away with it, because their application does all the right things > > to make it ok, but I don't think you can make a decsion like this for all users > > based on the request of a single user. > > > > It seems like the right thing is for OVS to augment their build time > > configuration to allow developers to select the ability to use experimental apis > > at compile time, and then the decision is placed in the hands of end users. > > So this is not isolated case right ... it is common from API's to graduate > from experimental to mature, we _want_ that to happen, we _want_ APIs to mature. > Sure, I can absolutely agree with that, though I would suggest that the maturity of the ABI is orthogonal to its labeling as such (more on that below) > I am worried what you are proposing will encourage a behavior whereby maintainers > to wait until the declaration of the next major ABI version to make these symbol changes, > causing these kinds of changes to queue up for that release. > I think you're probably right about that, and would make the agrument that thats perfectly fine (again I'll clarify below) > And you would have to ask why? > In the case of a reasonably mature API, there will be no functional or signature change - its mature! > So what is the harm of providing an alias back to Experimental until the next ABI version is declared? > >From a philosophical standpoint, there is absoluely no harm, and I don't think anyone would disagree, the harm comes from the details of the implementation, as you've noted. > So while yes, you are 100% right - experimental mean no guarantees. > But if the API is baked, it is not going to change, so I don't see the harm. > > We don't want the unnecessary triumph of policy over pragmatism. > I would make the converse argument here. While I agree that when an API is mature, theres no point in calling it experimental anymore, I would also suggest that, if an API is mature, and not expected to change, theres no harm in leaving its version tag as experimental for an LTS release. This is what I was referring to above. Once an application developer has done the work to integrate an API from DPDK into its application, that work is done. If the API remains stable, then I honestly don't know that they care that the version label is EXPERIMENTAL versus 20.11 or 20.05 or whatever. They care about the API being stable more so than its version label. As such, it seems....reasonable to me to have developers queue their migration of experimental APIs to official versioned APIs at the next major release deliniation point. I'd welcome counter arguments, but it seems pretty natural to me to make these sorts of changes at the major release mark. People using experimantal apis have already implicity agreed to manage changes to them, so if we just hold it stable in an LTS release (and don't update the version label), its just gravy for them. Regards Neil > > > > > >