From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id B283F58DF for ; Mon, 6 Jun 2016 13:48:41 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 06 Jun 2016 04:48:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,426,1459839600"; d="scan'208";a="991894603" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga002.jf.intel.com with ESMTP; 06 Jun 2016 04:48:37 -0700 Date: Mon, 6 Jun 2016 19:49:24 +0800 From: Yuanhan Liu To: Thomas Monjalon Cc: "Mcnamara, John" , dev@dpdk.org, Christian Ehrhardt , Markos Chandras , Panu Matilainen Message-ID: <20160606114924.GC10038@yliu-dev.sh.intel.com> References: <2142445.VVEujR2XLL@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2142445.VVEujR2XLL@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Mon, 06 Jun 2016 11:48:42 -0000 On Fri, Jun 03, 2016 at 06:05:15PM +0200, Thomas Monjalon wrote: > Hi, > > 2016-06-03 15:07, Mcnamara, John: > > Introduction > > ------------ > > > > This document sets out a proposal for a DPDK Long Term Support release (LTS). > > In general, LTS refer to a longer maintenance than than regular one. > Here we are talking to doing some maintenance as stable releases first. > Currently we have no maintenance at all. > So I suggest to differentiate "stable branches" and "LTS" for some stable branches. > > > 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. > [...] > > The proposed maintainer for the LTS is Yuanhan Liu > > . > > I wonder if Yuanhan is OK to maintain every stable releases which could be > requested/needed? I'm Okay, since I assume the maintain effort would be small: mainly for picking acked and tested *bug fix* patches. > Or should we have other committers for the stable releases > that Yuanhan would not want to maintain himself? > The Linux model is to let people declare themselves when they want to maintain > a stable branch. I have no object though, if somebody volunteer him as a stable branch maintainer. > > > The proposed duration of the LTS support is 2 years. > > I think we should discuss the support duration for each release separately. > > > 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. > > Seems a bit too restrictive. > Currently, there is no maintenance at all because nobody was volunteer. > If Yuanhan is volunteer for a stable branch every 2 years, fine. > If someone else is volunteer for other branches, why not let him do it? > > > 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. > > Let's do a first run with 16.07 and see later what we want to do next. > How long time a stable branch must be announced before its initial release? > > > What changes should be backported > > --------------------------------- > > > > * Bug fixes that don't break the ABI. > > And API? > And behaviour (if not clearly documented in the API)? Agreed, we should not include those changes, either. > > [...] > > 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. > > Why? > We must avoid putting too much restrictions on the contributors. This is actually requested by me, in a behaviour similar to Linux kernel community takes. Here is the thing, the developer normally knows better than a generic maintainer (assume it's me) that a patch applies to stable branch or not. This is especially true for DPDK, since we ask the developer to note down the bug commit by adding a fix line. It wouldn't be a burden for an active contributor, as CCing to related people (including right mailing list) is a good habit they already have. For some one-time contributors, it's okay that they don't know and follow it. In such case, I guess we need the help from the related subsystem maintainer: if it's a good bug fix that applies to stable branch, and the contributor forgot to make a explicit cc to stable mailing list, the subsystem maintainer should forward or ask him to forward to stable mailing list. The reason I'm asking is that as a generic maintainer, there is simply no such energy to keep an eye on all patches: you have to be aware of that we have thoughts of email per month from dpdk dev mailing list: the number of last month is 1808. Doing so would allow one person maintain several stable tree be possible. For more info, you could check linux/Documentation/stable_kernel_rules.txt. > > > 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. > > Thanks > It must not be just a tag. There should be an announce and a tarball ready > to download. Agreed. --yliu