From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id C4287A0613 for ; Wed, 25 Sep 2019 16:49:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8EDD51BF3A; Wed, 25 Sep 2019 16:49:17 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 9EE911041; Wed, 25 Sep 2019 16:49:16 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DF67F4DB1F; Wed, 25 Sep 2019 14:49:15 +0000 (UTC) Received: from [10.36.117.187] (ovpn-117-187.ams2.redhat.com [10.36.117.187]) by smtp.corp.redhat.com (Postfix) with ESMTP id 25B341001B07; Wed, 25 Sep 2019 14:49:11 +0000 (UTC) To: Bruce Richardson , Ray Kinsella Cc: dpdk-dev , "O'Driscoll, Tim" , Brian , "techboard@dpdk.org" References: <126e7de8-d2cd-d9f0-4fe8-d0d05963589f@ashroe.eu> <69a1da67-da6b-f004-7b84-279c55083e2e@redhat.com> <20190925144031.GA888@bricha3-MOBL.ger.corp.intel.com> From: Kevin Traynor Message-ID: <307773f1-6320-b984-b0fb-4cea57c83f1e@redhat.com> Date: Wed, 25 Sep 2019 15:49:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190925144031.GA888@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 25 Sep 2019 14:49:15 +0000 (UTC) Subject: Re: [dpdk-dev] [dpdk-techboard] [RFC] Proposals and notes from ABI stability panel @ DPDK Userspace 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" On 25/09/2019 15:40, Bruce Richardson wrote: > On Wed, Sep 25, 2019 at 03:29:16PM +0100, Ray Kinsella wrote: >> >>> In the short term, based on the feedback at the conference and to giv= e >>> something concrete to be considered, here is a suggestion, >>> >>> ABI freeze starts at 20.02 for 9 months, with a review as planned to = see >>> if 20.11 should be frozen 2 years. >>> >>> pros: >>> + Eliminates any need for delaying 19.11 release >>> >>> + Allows maintainers to stick to current deprecation policy if they n= eed >>> to make changes prior to freeze (Based on comment from Hemmant) >>> >>> + Not sure if it's worthy of a new bullet or clear from above but I >>> would add that changing the release cycle/deprecation policy etc 2 we= eks >>> (I think) before RC1 is late to say the least and there is no notice = to >>> users >>> >>> + Means that any changes required prior to freeze are not rushed with= >>> usual big LTS release (19.11). Gives more time and maybe during a san= er >>> release cycle (20.02) >>> >>> cons: >>> - With view for possible 20.11 freeze, gives 2 releases to tease out >>> process instead of 3 >>> >>> - Perhaps it is desirable for some users to have the 19.11 LTS ABI >>> compatible with 20.02/05/08 releases >>> >>> I've tried to keep them objective, of course people will have differe= nt >>> opinions about starting a freeze now vs. later etc. too. >>> >>> thanks, >>> Kevin. >>> >> >> *interesting* >> >> Another approach, possibly better approach, is to see the LTS as the >> final act following an ABI declaration/freeze. >> >> We we declare the v20 ABI in DPDK 20.02, and hold that ABI until 21.02= >> including the v20.11 LTS. The LTS then becomes the cumulation of the A= BI >> freeze. >> >> I didn't go this road, because of the community habit of pushing thing= s >> in just before the LTS, I thought it would be a bridge too far, and th= at >> it would get considerable push back. >=20 > I actually think this approach was initially rejected as having an ABI > break immediately after an LTS makes backporting fixes to the LTS more > problematic. >=20 Yeah, it likely would. I guess the freeze cycle or end date of the freeze trial (if i can call it that) could be discussed further later, but the start date is the more immediate issue now. > /Bruce >=20