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 04414A0A0C; Thu, 1 Jul 2021 12:19:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E610C40141; Thu, 1 Jul 2021 12:19:33 +0200 (CEST) Received: from mail-109-mta168.mxroute.com (mail-109-mta168.mxroute.com [136.175.109.168]) by mails.dpdk.org (Postfix) with ESMTP id CE4B840040 for ; Thu, 1 Jul 2021 12:19:32 +0200 (CEST) Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-109-mta168.mxroute.com (ZoneMTA) with ESMTPSA id 17a6194abca0002d34.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Thu, 01 Jul 2021 10:19:31 +0000 X-Zone-Loop: 61ff7137d8125bc62107d22193318c90dc251a9a71ed X-Originating-IP: [149.28.56.236] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ashroe.eu; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=HXjfPOOGkLrmlAC7P2Is/ymznXHY2SbDRwrQROiSKB0=; b=iEf4Pua24F0cMfPPqZjdZuoGbu apYoWapCa9ujlh07hKEJggspqL1vSXiI9BMrMCQ2hHrDYow866QYvnwDKRLne7UfbGVCLXbmrVwjQ Lpg4Z3p7MXOowSgIqBgPGRsr7VBpEO8zUQXzeCkBrj/zdC1QtSLRST/A9Y0BaHC/fgw7ITGysqQ27 iZrBMGHLXUm8HqDc70fu3jPnY+m5C/9be+3WKxEOCr20SBkahOayxn35M1dJXmy4dkDML2xDzcd9M GQ2WWg+qRh3pO3cdEDpattdQJVmV58GS3TsM+EXQoL9GODUHGvVF/5dpm3Sg3lgJ+tOfFUxnaw1EI WRrLEGEQ==; To: Tyler Retzlaff Cc: dev@dpdk.org, ferruh.yigit@intel.com, thomas@monjalon.net, david.marchand@redhat.com, stephen@networkplumber.org 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> From: "Kinsella, Ray" Message-ID: <670d7482-b3d2-70d3-4682-0f41dd7a2c8b@ashroe.eu> Date: Thu, 1 Jul 2021 11:19:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210630195617.GA24715@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AuthUser: mdr@ashroe.eu X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.1, required=15, tests=[ARC_NA=0, FROM_HAS_DN=0, TO_DN_SOME=0, MIME_GOOD=-0.1, FROM_EQ_ENVFROM=0, MIME_TRACE=0, RCVD_COUNT_ZERO=0, RCPT_COUNT_FIVE=0, MID_RHS_MATCH_FROM=0, NEURAL_SPAM=0] 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 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. 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. > >> >> However equally any changes to the implementation do not reset the clock. >> >> Would that work? > > that works for me. v2 on the way. > >> >>> >>>> + >>>> +The promotion or removal of symbols will typically form part of a conversation >>>> +between the maintainer and the original contributor. >>> >>> this should extend beyond just symbols. there are other changes that >>> impact the abi where exported symbols don't change. e.g. additions to >>> return values sets.> >>> thanks for working on this. >>>