From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 4CDB51BE0 for ; Sun, 14 Jan 2018 17:28:11 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9514C20BB3; Sun, 14 Jan 2018 11:28:10 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 14 Jan 2018 11:28:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=kfPwu0/Sh3P21xOSExK+9JqPIl rS89FFM1GjLy0hVIQ=; b=gtmdREnzaRkJNUnCEitpcsYhNhoijDrjxebPZBtVeq ghmyycBdqNzn9FYa/y187HMzNXlEfwf5p8F+Yao6gymD+ibNIdoWGw+7Lgxx2fWP uDrH+zH8zHSvAqB6IGSkx7fK55VT5R8VI6OoGjygDfy7rBiAzPXgwH/smBY0elgx Q= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=kfPwu0 /Sh3P21xOSExK+9JqPIlrS89FFM1GjLy0hVIQ=; b=l2tltXaY8p2nkKC636VIaH aCRZhmWYH/uNe0voNaDjug9roQysuertvSON5MSpn/2TO53jpoe7fKmBY0jf1Vl2 +U1ASkqHCmMSYkqLuOba/5hBqctOF+T7Ajp7mVPoZ7um3ZsSs29oeWGtPCbYttBT W5pIbVojmH2UOmG2hU/hTJU8ObRFRdnYtX3Q6r4XnMcsuQE5E/lfANOCgyPfE6Vv tsgzqagfx4HX9RwW7s8GycG57+IYLYEGjyCQGdqyxA/MRAHQd+dqk85CSrQ+StIb oylaUNJD8GtJe2JvSDQ0+5+QTNWu/SPthjxog70XcpNWxUDE5C/e4byE/lBdBq6g == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 44BD77E1A2; Sun, 14 Jan 2018 11:28:10 -0500 (EST) From: Thomas Monjalon To: Neil Horman Cc: Ferruh Yigit , dev@dpdk.org, john.mcnamara@intel.com, bruce.richardson@intel.com Date: Sun, 14 Jan 2018 17:27:39 +0100 Message-ID: <4126394.lds5JWlh5s@xps> In-Reply-To: <20180114143648.GA25083@neilslaptop.think-freely.org> References: <20171201185628.16261-1-nhorman@tuxdriver.com> <10180523.pVSGtVxuBN@xps> <20180114143648.GA25083@neilslaptop.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 16:28:11 -0000 14/01/2018 15:36, Neil Horman: > 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 am OK with this approach. > I'll start work on that on monday Good I wonder how difficult it can be to implement. Note: we do not maintain a fork of checkpatch.pl. We just have a shell wrapper checkpatch.sh. Maybe you should start a different tool. Can it use Coccinelle?