From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <bruce.richardson@intel.com> Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id EDCAF5F2E for <dev@dpdk.org>; Mon, 15 Apr 2019 11:11:29 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Apr 2019 02:10:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,353,1549958400"; d="scan'208";a="149507333" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.220.103]) by FMSMGA003.fm.intel.com with SMTP; 15 Apr 2019 02:10:28 -0700 Received: by (sSMTP sendmail emulation); Mon, 15 Apr 2019 10:10:27 +0100 Date: Mon, 15 Apr 2019 10:10:27 +0100 From: Bruce Richardson <bruce.richardson@intel.com> To: Neil Horman <nhorman@tuxdriver.com> Cc: Ray Kinsella <mdr@ashore.eu>, dev@dpdk.org Message-ID: <20190415091026.GA1846@bricha3-MOBL.ger.corp.intel.com> References: <c0856556-a42e-d0cf-6a01-6279643c8089@ashroe.eu> <d9edf2cb-6894-b794-1402-0e1d11701deb@ashroe.eu> <455a61b4-891d-eaaf-d784-2be884bcacbd@intel.com> <7166381.CkH77a7QuE@xps> <5e27f573-bbf5-30f1-73ee-d35fc5191632@ashroe.eu> <20190414004202.GA29726@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190414004202.GA29726@hmswarspite.think-freely.org> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 15 Apr 2019 09:11:30 -0000 On Sat, Apr 13, 2019 at 08:42:02PM -0400, Neil Horman wrote: > On Mon, Apr 08, 2019 at 10:04:21AM +0100, Ray Kinsella wrote: > > On 07/04/2019 10:48, Thomas Monjalon wrote: > > > 04/04/2019 16:07, Burakov, Anatoly: > > >> On 04-Apr-19 1:52 PM, Ray Kinsella wrote: > > >>> On 04/04/2019 11:54, Bruce Richardson wrote: > > >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote: > > >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote: > > [SNIP] > > >> So, if we are to cement our core API - we have to make a concrete effort > > >> to specify what goes and what stays, if we want it to be maintainable. > > >> The DPDK 1.0 specification, if you will :) > > > > > > "DPDK 1.0 specification", that's a great project name :-) > > > > > > > Honestly - I would say that I am nervous of this. > > > > The definition of a DPDK 1.0 specification as a gate to API stability, > > feels like a "great plan tomorrow" instead of a "good plan" today. I > > think that getting people to dedicate time to such a specification might > > prove problematic and I could see this effort being very time consuming. > > It might never get completed. > > > > My preference would be to instead adopt a well-publicised community > > timeline for adopting more conservative API maintenance rules. > > > > Perhaps we could give ourselves as a community a time-limited window in > > which to address concerns around the API before they become hardened - > > perhaps say until DPDK 19.11 LTS, or something of the order of 6 months > > to 9 months. > > > > We then would know the timeline when niggles like exposure of internal > > structures and mbuf structure needed to be sorted by and could > > prioritize accordingly. > > > > Ray K > > I'm hesitant to say this, because I'm not usually a fan of throwing up > barricades to progress, but might some level of CI integration be useful here? > > Part of the problem, as I've seen it (and I think you've noted previously in > this thread), is that ABI stability just hasn't been a priority, and not > something that developers look at when making changes, nor when reviewers review > patches. When I wrote the early ABI checking tools for DPDK, while the reaction > was generally positive (I think), the results were informational, and treated as > such (something to take note of perhaps, but something that could be ignored if > there were more pressing issues). Perhaps a concrete step might be to run the > ABI checker during a CI run on every commit, and block acceptance of a patch if > it modifies the ABI. That would at least put a procedural break in ABI > modification without clear approval from the board. > No objections to that here. Sounds a reasonable suggestion. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 2E580A00E6 for <public@inbox.dpdk.org>; Mon, 15 Apr 2019 11:11:33 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CB17E1B136; Mon, 15 Apr 2019 11:11:32 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id EDCAF5F2E for <dev@dpdk.org>; Mon, 15 Apr 2019 11:11:29 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Apr 2019 02:10:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,353,1549958400"; d="scan'208";a="149507333" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.220.103]) by FMSMGA003.fm.intel.com with SMTP; 15 Apr 2019 02:10:28 -0700 Received: by (sSMTP sendmail emulation); Mon, 15 Apr 2019 10:10:27 +0100 Date: Mon, 15 Apr 2019 10:10:27 +0100 From: Bruce Richardson <bruce.richardson@intel.com> To: Neil Horman <nhorman@tuxdriver.com> Cc: Ray Kinsella <mdr@ashore.eu>, dev@dpdk.org Message-ID: <20190415091026.GA1846@bricha3-MOBL.ger.corp.intel.com> References: <c0856556-a42e-d0cf-6a01-6279643c8089@ashroe.eu> <d9edf2cb-6894-b794-1402-0e1d11701deb@ashroe.eu> <455a61b4-891d-eaaf-d784-2be884bcacbd@intel.com> <7166381.CkH77a7QuE@xps> <5e27f573-bbf5-30f1-73ee-d35fc5191632@ashroe.eu> <20190414004202.GA29726@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <20190414004202.GA29726@hmswarspite.think-freely.org> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> Message-ID: <20190415091027.nQ1zoiBJiF7LCZA0rZw0gBsScyJ2EInNkdUyocnK-B8@z> On Sat, Apr 13, 2019 at 08:42:02PM -0400, Neil Horman wrote: > On Mon, Apr 08, 2019 at 10:04:21AM +0100, Ray Kinsella wrote: > > On 07/04/2019 10:48, Thomas Monjalon wrote: > > > 04/04/2019 16:07, Burakov, Anatoly: > > >> On 04-Apr-19 1:52 PM, Ray Kinsella wrote: > > >>> On 04/04/2019 11:54, Bruce Richardson wrote: > > >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote: > > >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote: > > [SNIP] > > >> So, if we are to cement our core API - we have to make a concrete effort > > >> to specify what goes and what stays, if we want it to be maintainable. > > >> The DPDK 1.0 specification, if you will :) > > > > > > "DPDK 1.0 specification", that's a great project name :-) > > > > > > > Honestly - I would say that I am nervous of this. > > > > The definition of a DPDK 1.0 specification as a gate to API stability, > > feels like a "great plan tomorrow" instead of a "good plan" today. I > > think that getting people to dedicate time to such a specification might > > prove problematic and I could see this effort being very time consuming. > > It might never get completed. > > > > My preference would be to instead adopt a well-publicised community > > timeline for adopting more conservative API maintenance rules. > > > > Perhaps we could give ourselves as a community a time-limited window in > > which to address concerns around the API before they become hardened - > > perhaps say until DPDK 19.11 LTS, or something of the order of 6 months > > to 9 months. > > > > We then would know the timeline when niggles like exposure of internal > > structures and mbuf structure needed to be sorted by and could > > prioritize accordingly. > > > > Ray K > > I'm hesitant to say this, because I'm not usually a fan of throwing up > barricades to progress, but might some level of CI integration be useful here? > > Part of the problem, as I've seen it (and I think you've noted previously in > this thread), is that ABI stability just hasn't been a priority, and not > something that developers look at when making changes, nor when reviewers review > patches. When I wrote the early ABI checking tools for DPDK, while the reaction > was generally positive (I think), the results were informational, and treated as > such (something to take note of perhaps, but something that could be ignored if > there were more pressing issues). Perhaps a concrete step might be to run the > ABI checker during a CI run on every commit, and block acceptance of a patch if > it modifies the ABI. That would at least put a procedural break in ABI > modification without clear approval from the board. > No objections to that here. Sounds a reasonable suggestion.