From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCHv4 5/5] doc: Add ABI __experimental tag
	documentation
Date: Sat, 13 Jan 2018 16:56:11 +0100
Message-ID: <10180523.pVSGtVxuBN@xps>
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: Ferruh Yigit <ferruh.yigit@intel.com>, dev@dpdk.org,
 john.mcnamara@intel.com, bruce.richardson@intel.com
To: Neil Horman <nhorman@tuxdriver.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
 [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id ED5442BC8
 for <dev@dpdk.org>; Sat, 13 Jan 2018 16:56:42 +0100 (CET)
In-Reply-To: <20180113002840.GA17575@neilslaptop.think-freely.org>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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.