From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 286865583 for ; Sun, 5 Jun 2016 20:15:25 +0200 (CEST) Received: from [107.15.76.160] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1b9cZv-0005L6-6V; Sun, 05 Jun 2016 14:15:20 -0400 Date: Sun, 5 Jun 2016 14:15:13 -0400 From: Neil Horman To: "Mcnamara, John" Cc: dev , Christian Ehrhardt , Markos Chandras , Panu Matilainen Message-ID: <20160605181513.GA11762@neilslaptop.think-freely.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Score: -1.0 (-) X-Spam-Status: No 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 18:15:25 -0000 On Fri, Jun 03, 2016 at 03:07:49PM +0000, Mcnamara, John wrote: > Introduction > ------------ > > This document sets out a proposal for a DPDK Long Term Support release (LTS). > > The purpose of the DPDK LTS will be to maintain a stable release of DPDK with > backported bug fixes over an extended period of time. This will provide > downstream consumers of DPDK with a stable target on which to base > applications or packages. > > As with previous DPDK guidelines this proposal is open for discussion within > the community. The consensus view will be included in the DPDK documentation > as a guideline. > > > LTS Maintainer > -------------- > > The proposed maintainer for the LTS is Yuanhan Liu > . > > > LTS Duration > ------------ > > The proposed duration of the LTS support is 2 years. > > There will only be one LTS branch being maintained at any time. At the end of > the 2 year cycle the maintenance on the previous LTS will be wound down. > > > LTS Version > ------------ > > The proposed initial LTS version will be DPDK 16.07. The next versions, based > on a 2 year cycle, will be DPDK 18.08, 20.08, etc. > > > What changes should be backported > --------------------------------- > > * Bug fixes that don't break the ABI. > > > What changes should not be backported > ------------------------------------- > > * API or ABI breaking changes. > > * Features should not be backported. Unless: > > * There is a justifiable use case (for example a new PMD). > * The change is non-invasive. > * The work of preparing the backport is done by the proposer. > * There is support within the community. > > > Role of the maintainer > ---------------------- > > * The maintainer will evaluate fixes to the DPDK master submitted by the > fixing developer and apply them to the LTS branch/tree. > > * The maintainer will evaluate backported patches from downstream consumers > and apply them to the LTS branch/tree. > > * The maintainer will not backport non-trivial fixes without assistance from > the downstream consumers or requester. > > > Role of the downstream consumers > -------------------------------- > > Developers submitting fixes to the mainline should also CC the maintainer so > that they can evaluate the patch. A email address could be > provided for this so that it can be included as a CC in the commit messages > and documented in the Code Contribution Guidelines. > > The downstream consumers (OSVs and DPDK dependent application and framework > developers) should identify issues in the field that have been fixed in the > mainline release and report them to the maintainer. They should, ideally, > assist with backporting any required fixes. > > > Testing > ------- > > Intel will provide validation engineers to test the LTS branch/tree. Tested > releases can be marked using a Git tag with an incremented revision number. For > example: 16.07.00_LTS -> 16.07.01_LTS. The testing cadence should be quarterly > but will be best effort only and dependent on available resources. > > > Validated OSes > -------------- > > In order to reduce the testing effort the number of OSes which will be > officially validated should be as small as possible. The proposal is that the > following long term OSes are used for validation: > > (OSV reps please confirm.) > > * Ubuntu 16.04 LTS > * RHEL 7.3 > * SuSE 11 SP4 or 12 > * FreeBSD 10.3 > > Fixes for newer OSes, kernels (and associated KNI fixes), and newer GCC/Clang > versions can be backported but the validation effort will be limited to the > above platforms. > > > Release Notes > ------------- > > The LTS release notes should be updated to include a section with backported > fixes. Patches for backporting should include additions to the release notes > like patches to the mainline branch. > > > LTS Review > ---------- > > The LTS guidelines shall be reviewed after 1 year to adjust for any experiences > from LTS maintainership. > > > > > > > I'm not opposed to an LTS release, but it seems to be re-solving the issue 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: 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 Those two mechanism are expressly intended to allow application upgrades of DPDK libraries without worrying about ABI breakage. 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 LTS is a fine process for projects in which API/ABI breakage is either uncommon or fairly isolated, but that in my mind doesn't really describe DPDK. Neil