From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A0E8AA0A0C; Thu, 1 Jul 2021 17:09:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 628B340141; Thu, 1 Jul 2021 17:09:25 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 35A3E4003E for ; Thu, 1 Jul 2021 17:09:24 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id 8893220B7178; Thu, 1 Jul 2021 08:09:23 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8893220B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1625152163; bh=cDdrI+m5+AxwXjinOdI+bJvapR9cEtckE1P1Rm5jSpo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bwBzvx0/QXY86xX9b5gurKLShJpBjFABoluo3n/KAT9brCYb3VbWUx4Kj9GKZNqhc UE13WtKND+zLBM8K88xhySdr4wD8R+sQ/vVnoG46c3yIsQkkf7tpL4+sX0DUXZ93ew FyINT5unyQqmssHDy8/iFxdzNESEhDnc8+JBKwp4= Date: Thu, 1 Jul 2021 08:09:23 -0700 From: Tyler Retzlaff To: "Kinsella, Ray" Cc: dev@dpdk.org, ferruh.yigit@intel.com, thomas@monjalon.net, david.marchand@redhat.com, stephen@networkplumber.org Message-ID: <20210701150923.GB4202@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20210629160031.74681-1-mdr@ashroe.eu> <20210629162837.GB27963@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <46fa9dec-cee0-ba7f-13a0-11ee42419ee5@ashroe.eu> <20210630195617.GA24715@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <670d7482-b3d2-70d3-4682-0f41dd7a2c8b@ashroe.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <670d7482-b3d2-70d3-4682-0f41dd7a2c8b@ashroe.eu> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dpdk-dev] [PATCH v1] doc: policy on promotion of experimental APIs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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, Jul 01, 2021 at 11:19:27AM +0100, Kinsella, Ray wrote: > > > On 30/06/2021 20:56, Tyler Retzlaff wrote: > > On Tue, Jun 29, 2021 at 07:38:05PM +0100, Kinsella, Ray wrote: > >> > >> > >>>> +Promotion to stable > >>>> +~~~~~~~~~~~~~~~~~~~ > >>>> + > >>>> +Ordinarily APIs marked as ``experimental`` will be promoted to the stable API > >>>> +once a maintainer and/or the original contributor is satisfied that the API is > >>>> +reasonably mature. In exceptional circumstances, should an API still be > >>> > >>> this seems vague and arbitrary. is there a way we can have a more > >>> quantitative metric for what "reasonably mature" means. > >>> > >>>> +classified as ``experimental`` after two years and is without any prospect of > >>>> +becoming part of the stable API. The API will then become a candidate for > >>>> +removal, to avoid the acculumation of abandoned symbols. > >>> > >>> i think with the above comment the basis for removal then depends on > >>> whatever metric is used to determine maturity. > >>> if it is still changing > >>> then it seems like it is useful and still evolving so perhaps should not > >>> be removed but hasn't changed but doesn't meet the metric for being made > >>> stable then perhaps it becomes a candidate for removal. > >> > >> Good idea. > >> > >> I think it is reasonable to add a clause that indicates that any change > >> to the "API signature" would reset the clock. > > > > a time based strategy works but i guess the follow-on to that is how is > > the clock tracked and how does it get updated? i don't think trying to > > troll through git history will be effective. > > > > one nit, i think "api signature" doesn't cover all cases of what i would > > regard as change. i would prefer to define it as "no change where api/abi > > compatibility or semantic change occurred"? which is a lot more strict > > but in practice is necessary to support binaries when abi/api is stable. > > > > i.e. if a recompile is necessary with or without code change then it's a > > change. > > Having thought a bit ... this becomes a bit problematic. > > Many data-structures in DPDK are nested, > these can have a ripple effect when changed - a change to mbuf is a good example. > > What I saying is ... > I don't think changes in ABI due to in-direct reasons should count. > If there is a change due to a deliberate change in the ABI signature > that is fine, reset the clock. > > > If there is a change due to some nested data-structure, > 3-levels down changing in my book that doesn't count. it has to count otherwise dpdk's abi stability promise for major version releases is meaningless. or are you suggesting it doesn't count for the purpose of determining whether or not an experimental api/abi has changed? > As that may or may not have been deliberate, and is almost impossible to police. > > Checking anything but a deliberate change to the ABI signature, > would be practically impossible IMHO. well, it isn't impossible but it does take knowledge, mechanism and process maintain the abi for a major version.