From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id D5FDE1BE0 for ; Sun, 14 Jan 2018 15:37:18 +0100 (CET) Received: from [107.15.66.59] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1eajP1-0006YH-61; Sun, 14 Jan 2018 09:37:03 -0500 Date: Sun, 14 Jan 2018 09:36:48 -0500 From: Neil Horman To: Thomas Monjalon Cc: Ferruh Yigit , dev@dpdk.org, john.mcnamara@intel.com, bruce.richardson@intel.com Message-ID: <20180114143648.GA25083@neilslaptop.think-freely.org> References: <20171201185628.16261-1-nhorman@tuxdriver.com> <2ba5be68-4d5d-9f37-e86a-fe23b6708056@intel.com> <20180113002840.GA17575@neilslaptop.think-freely.org> <10180523.pVSGtVxuBN@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10180523.pVSGtVxuBN@xps> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCHv4 5/5] doc: Add ABI __experimental tag documentation 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: , X-List-Received-Date: Sun, 14 Jan 2018 14:37:19 -0000 On Sat, Jan 13, 2018 at 04:56:11PM +0100, Thomas Monjalon wrote: > 13/01/2018 01:28, Neil Horman: > > On Fri, Jan 12, 2018 at 03:55:10PM +0000, Ferruh Yigit wrote: > > > After this point agree to using EXPERIMENTAL tag in the version map as standard, > > > but it will be hard to maintain "API is experimental for first release" without > > > help of any automated tool. > > > > > I completely agree, in fact I would say it is impossible to do without tooling, > > with or without this change. I think we need to do 1 of 2 things: > > > > 1) Add some code to checkpatch.pl to put up a warning if any new apis are added > > without marking them as experimental > > > > 2) Change the documentation to be a suggestion rather than a requirement. > > > > I'll look into doing (1), but I'm wondering if (2) is the more flexible way to > > go. I'm hesitant to enforce the initial marking of new APIs as experimental. > > Thoughts? > > There will be always cases where we are sure that the experimental step > is not needed. > Even if it is required and checked by a tool, we can ignore it, right? > However, there is no big benefit of bypassing the experimental step. > > I am for making mandatory the new API as experimental. > We will handle the exceptions case by case if any. > If the consensus is to require experimental marking by default, and grant exceptions as needed, then I would strongly suggest that we do this in checkpatch as I can modify it to warn people of added API's (which will be reflected in the CI tool, if the CI group is still maintaining it), but we can collectively ignore it if its so clearly trivial that it requires no experimental addition (which I think may freqently be the case). I'll start work on that on monday Best Neil