From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 742C6C11F65 for ; Wed, 30 Jun 2021 19:56:21 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id D33EF61461 for ; Wed, 30 Jun 2021 19:56:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D33EF61461 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D9F5240141; Wed, 30 Jun 2021 21:56:19 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 5396140040 for ; Wed, 30 Jun 2021 21:56:18 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id 9F3F020B7178; Wed, 30 Jun 2021 12:56:17 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 9F3F020B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1625082977; bh=q87nyzXjdJREh108/VZpqjWMrQb2XReUvhzxhkaRuH4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YSovaeGwwspv6w0/dHu8xDSDL5tXLzjlD1e0IjLXpLDU1/fk3AdGRcsq7UVJHoEjV JqeNdrh6I8a7Jo1qs/2LwYsOaQP9X6B9oReBfTTuszViUioP14lVJHH5ZqPDnlwW2T njwdWLMUWtkTKVLknGMSGRT0xVw2Wad1+N6eyg70= Date: Wed, 30 Jun 2021 12:56:17 -0700 From: Tyler Retzlaff To: "Kinsella, Ray" Cc: dev@dpdk.org, ferruh.yigit@intel.com, thomas@monjalon.net, david.marchand@redhat.com, stephen@networkplumber.org Message-ID: <20210630195617.GA24715@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20210629160031.74681-1-mdr@ashroe.eu> <20210629162837.GB27963@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <46fa9dec-cee0-ba7f-13a0-11ee42419ee5@ashroe.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46fa9dec-cee0-ba7f-13a0-11ee42419ee5@ashroe.eu> User-Agent: Mutt/1.5.21 (2010-09-15) 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 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. > > However equally any changes to the implementation do not reset the clock. > > Would that work? that works for me. > > > > >> + > >> +The promotion or removal of symbols will typically form part of a conversation > >> +between the maintainer and the original contributor. > > > > this should extend beyond just symbols. there are other changes that > > impact the abi where exported symbols don't change. e.g. additions to > > return values sets.> > > thanks for working on this. > >