From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 8D764A0679 for ; Thu, 4 Apr 2019 22:13:10 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 53A491B1F5; Thu, 4 Apr 2019 22:13:10 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 634B01B1F3; Thu, 4 Apr 2019 22:13:09 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5512919D384; Thu, 4 Apr 2019 20:13:08 +0000 (UTC) Received: from [10.40.205.77] (unknown [10.40.205.77]) by smtp.corp.redhat.com (Postfix) with ESMTP id 94F3717D42; Thu, 4 Apr 2019 20:13:06 +0000 (UTC) To: "Wiles, Keith" Cc: "Richardson, Bruce" , "Burakov, Anatoly" , Ray Kinsella , dpdk-dev , "techboard@dpdk.org" References: <94df3cc4-de54-72d6-84c6-81bebd209a81@intel.com> <20190404105447.GA1351@bricha3-MOBL.ger.corp.intel.com> <3d4dfde3-cf8c-8220-18a3-1542567cc3eb@redhat.com> From: Kevin Traynor Message-ID: Date: Thu, 4 Apr 2019 21:13:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 04 Apr 2019 20:13:08 +0000 (UTC) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190404201305.jIQhDI4vFKbXYCqn6xwLUBZhiMenWINifZDGxHEwTZY@z> On 04/04/2019 20:08, Wiles, Keith wrote: > > >> On Apr 4, 2019, at 11:56 AM, Kevin Traynor wrote: >> >> On 04/04/2019 11:54, Bruce Richardson wrote: >> >> >>> >>> My thoughts on the matter are: >>> 1. I think we really need to do work to start hiding more of our data >>> structures - like what Stephen's latest RFC does. This hiding should reduce >>> the scope for ABI breaks. >>> 2. Once done, I think we should commit to having an ABI break only in the >>> rarest of circumstances, and only with very large justification. I want us >>> to get to the point where DPDK releases can immediately be picked up by all >>> linux distros and rolled out because they are ABI compatible. >>> >> >> Maybe techboard should explicitly approve ABI breaks and new APIs (or >> APIs at transition from experimental to core). Just as a way to get more >> eyeballs and scrutiny on them. > > ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while. >> We'll only find out if they are bad when they need ABI breaks later :-) My point is a good way to avoid future ABI breaks is to have more reviews on the APIs in the first place. Techboard approval might be one way, or 3 acks or something else. >>> I'm not sure I like the idea of planned ABI break releases - that strikes >>> me as a plan where we end up with the same number of ABI breaks as before, >>> just balled into one release. >>> >>> Question for Kevin, Luca and others who look at distro-packaging: is it the >>> case that each distro will only ship one version of DPDK, or is it possible >>> that if we have ABI breaks, a distro will provide two copies of DPDK >>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version? >>> >> >> It would probably double validation and maintenance, so it would require >> a lot of extra effort. >> >>> >>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK >>> ABI breaks, and having ABI breaks as a major event reserved only for >>> massive rework changes, such as major mbuf changes, or new memory layout or >>> similar. >>> >>> Regards, >>> /Bruce >>> >> > > Regards, > Keith >