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 93177A0A0C; Fri, 2 Jul 2021 08:30:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 50A3B40141; Fri, 2 Jul 2021 08:30:47 +0200 (CEST) Received: from mail-108-mta174.mxroute.com (mail-108-mta174.mxroute.com [136.175.108.174]) by mails.dpdk.org (Postfix) with ESMTP id 9CD984003E for ; Fri, 2 Jul 2021 08:30:45 +0200 (CEST) Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta174.mxroute.com (ZoneMTA) with ESMTPSA id 17a65e9850e0002d34.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 02 Jul 2021 06:30:40 +0000 X-Zone-Loop: 405a9b66474bd131ef93939800c899a5a13cf029331c 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=zFvTrsLKWwsalC4nJvhywOtaqCBQOsm/KA0jAqfIpr8=; b=Vhkk41KmUgi3B1fn5pShMFKZMm aChssZJapsLGGTFEvPtkuG+g09eRPkHvUVl7sdDVgZwzur6bqhJdUcQ+U3CYEiIGS2Jnq2rJkqfot xSAIf9U3UtosakXSmu4BFBFKde7gm6oZMfrV9Xr9SFaCj2faHP4hM1bByof6mJGl5S779c9c2AxDS reXYSBlvkbkOOvGKx2xxwIZ4PukxuMsVyFLKl5rcts2Y56p6mpiVVRkdfqnOkbljGdSLT2NjtIPio 7CvYe4IOKjmvDcbCV6EInh/oD7/pFYyBdnRJ5PNQPXjWW9/yaEAIrHfvknIU32wuA9Xma8PdKOZrX yKuFmErg==; 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> <670d7482-b3d2-70d3-4682-0f41dd7a2c8b@ashroe.eu> <20210701150923.GB4202@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: "Kinsella, Ray" Message-ID: <6c86968c-2f7d-92d7-28b5-becf822b5498@ashroe.eu> Date: Fri, 2 Jul 2021 07:30:37 +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: <20210701150923.GB4202@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 01/07/2021 16:09, Tyler Retzlaff wrote: > 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? "it doesn't count for the purpose of determining whether or not an experimental api/abi has changed?". Exactly - that is what I meant - apologies if I was unclear. In this case the change is not a deliberate act, in that it is not really happening because of any maturing of the ABI. > >> 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. 100% agree with this statement. What do you think of the v3?