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 ED5442BC8 for ; Sat, 13 Jan 2018 16:56:42 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6DE3B20E19; Sat, 13 Jan 2018 10:56:42 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 13 Jan 2018 10:56:42 -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=di30s0ac/ieFRb9KFWw8Q3WpF0 SFR8m8I8KwabwABWM=; b=Ej+UjK6v1huCZY0J7t0qqpsVe0RmhRLVUCFgeZLpDA moSXlUi/bYCE/GiJW7EuzBmW0Eit+Tmi+tBbVFS5LsnwRxRH+XaLgZ01ycrySHlX Wa0zZWBh8ivp5rxlm52vO3Ai/c+hMkPUD3BrXwRRmTh4YOfGoOhgJwmUJ4R9bkBw 0= 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=di30s0 ac/ieFRb9KFWw8Q3WpF0SFR8m8I8KwabwABWM=; b=dkuhYfTB7j+wPMSfpj9Q1j sPbTC0n69gbEM62UjeClUef0H/yXVcu6VFDRMkrcXGYDUzyL7tfDVRdNrlXzZb+v Hjfpn2skV0N6p1WgySUH3qNjfuBo4uElabQ1NmHD83FaNqdBGi/96wWswtLIACUW KcfmlobeOntB8ZdocL6t0W5vVBYZ13O8gDZUMUb/PupUl8FCrqU0Rw8v1K62RjcL VJl+t5i8x2tisMnqT1PLURB45iS42ToYWVAzPqKK4LbZjEHkLFleR04PxHekr4Xg Nuvw1Gqhk43p+ldUGtfDOsOJPYxR4SrTWm/MRi1dt1drBm+PPXvbY2bIPg9Sx9lA == 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 20FC67E335; Sat, 13 Jan 2018 10:56:42 -0500 (EST) From: Thomas Monjalon To: Neil Horman Cc: Ferruh Yigit , dev@dpdk.org, john.mcnamara@intel.com, bruce.richardson@intel.com Date: Sat, 13 Jan 2018 16:56:11 +0100 Message-ID: <10180523.pVSGtVxuBN@xps> In-Reply-To: <20180113002840.GA17575@neilslaptop.think-freely.org> References: <20171201185628.16261-1-nhorman@tuxdriver.com> <2ba5be68-4d5d-9f37-e86a-fe23b6708056@intel.com> <20180113002840.GA17575@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: Sat, 13 Jan 2018 15:56:43 -0000 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.