From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <john.mcnamara@intel.com>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
 by dpdk.org (Postfix) with ESMTP id 867019611
 for <dev@dpdk.org>; Tue,  7 Jun 2016 17:56:00 +0200 (CEST)
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
 by orsmga102.jf.intel.com with ESMTP; 07 Jun 2016 08:55:59 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.26,433,1459839600"; d="scan'208";a="715309332"
Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99])
 by FMSMGA003.fm.intel.com with ESMTP; 07 Jun 2016 08:55:57 -0700
Received: from irsmsx103.ger.corp.intel.com ([169.254.3.240]) by
 IRSMSX107.ger.corp.intel.com ([169.254.10.96]) with mapi id 14.03.0248.002;
 Tue, 7 Jun 2016 16:55:57 +0100
From: "Mcnamara, John" <john.mcnamara@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
CC: dev <dev@dpdk.org>, Christian Ehrhardt <christian.ehrhardt@canonical.com>, 
 Markos Chandras <mchandras@suse.de>, Panu Matilainen <pmatilai@redhat.com>
Thread-Topic: [dpdk-dev] RFC: DPDK Long Term Support
Thread-Index: AdG9qZjkO0DgyHDnRPC8xMkMMP+0dQBpDlKAAGEOgvA=
Date: Tue, 7 Jun 2016 15:55:56 +0000
Message-ID: <B27915DBBA3421428155699D51E4CFE20257CE14@IRSMSX103.ger.corp.intel.com>
References: <B27915DBBA3421428155699D51E4CFE20257B8E3@IRSMSX103.ger.corp.intel.com>
 <20160605181513.GA11762@neilslaptop.think-freely.org>
In-Reply-To: <20160605181513.GA11762@neilslaptop.think-freely.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ctpclassification: CTP_PUBLIC
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzg3OTA5M2MtYmIxNS00NjI2LTgwNWUtM2Y3Y2MwZTEwYjIzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS45LjYuNiIsIlRydXN0ZWRMYWJlbEhhc2giOiJQTjNhVm81WFRMRHF5QlJ3RXY4ekh1OTFWV3VRVlQ5TGhNNWE0Q0ZMSFBjPSJ9
x-originating-ip: [163.33.239.180]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] RFC: DPDK Long Term Support
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://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: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jun 2016 15:56:00 -0000



> -----Original Message-----
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Sunday, June 5, 2016 7:15 PM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev <dev@dpdk.org>; Christian Ehrhardt
> <christian.ehrhardt@canonical.com>; Markos Chandras <mchandras@suse.de>;
> Panu Matilainen <pmatilai@redhat.com>
> Subject: Re: [dpdk-dev] RFC: DPDK Long Term Support
>=20
> >
> I'm not opposed to an LTS release, but it seems to be re-solving the issu=
e
> of ABI breakage.  That is to say, there is alreay a process in place for
> managing ABI changes to the DPDK, which is designed to help ensure that:
>=20
> 1) ABI changes are signaled at least 2 releases early
> 2) ABI changes whenever possible are designed such that backward
> compatibility versions can be encoded at the same time with versioning
> tags
>=20
> Those two mechanism are expressly intended to allow application upgrades
> of DPDK libraries without worrying about ABI breakage. =20

Hi,

The purpose of the LTS proposal isn't to replace or circumvent the ABI poli=
cy.
In fact backporting of patches would be very difficult without an upstream
ABI policy.

Even if the ABI policy was working perfectly there would still be a use cas=
e
for an LTS among consumers who want a fixed version with bug fixes or minor
changes. There are already several companies maintaining their own branches
like this. This purpose of this proposal is to get them to converge on a=20
single version (or, if there is support, versions) and combine their effort=
s.


> While LTS releases
> are a fine approach for  some things, they sacrifice upstream efficiency
> (by creating work for backporting teams), while allowing upstream
> developers more leverage to just create ABI breaking changes on a whim,
> ignoring the existing ABI compatibility mechanism


An LTS release doesn't prevent us from maintaining upstream ABI compatibili=
ty
and it only gives developers leverage if we allow it to.

John.
--=20