From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id BE3FB2BF0 for ; Mon, 6 Jun 2016 11:17:14 +0200 (CEST) Received: by mail-wm0-f44.google.com with SMTP id r5so1379372wmr.0 for ; Mon, 06 Jun 2016 02:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=UyxMnuzfgjZQN29rvNzRZetkcedgprvPdSgyf4hBnoY=; b=kHqF8LcTbxljIv/I4lsJ+N6RKvILxxJvf5deQvaDNAJKtJUPTmvsFtcDDZUumVZTq5 k1EOKhM8sm5yQuJZka+T4H1hTOSHTjN532j6L2/FT0Io/xuZ3JWObIggyhTF3UkoAlEj YAO0DsEdWApZlmQgTGQnMLOdAwANnocUkj6MXt1Z//Em8h8w3ivgS+wbMw0fVTD8Sghq Phn0kCN/G/iySWeySD1IMYTbk4toyfavNIBKARMVnUovdgLencJjFJQI6bRQQ6x4uP/R TF4Z/oa7ZWd0/eW/z4Cl0KJpP4kNK+7SX+QxR9259x+9ECnULXQL24ZNkkSTl6mB7p+C sFWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=UyxMnuzfgjZQN29rvNzRZetkcedgprvPdSgyf4hBnoY=; b=cvd+bbhZFl2tOxrPGNqjZd1R7C5WCw1cdhhdQOEuDXeafKHWR4Jb/YjT6gSr3iwXWT t29nzg6XvvknSvA+afmTmO7ae7a8YqayzwX5VGtFP6z1HsKKaz1ANHYx8ilrvL2bYKdv l9JijUThsiFyW9+bqWamA32Rjv4aTvVlQApfqgF49gknGVtyh0oahqeghuyRxL0QQnh5 TrJzc6EzhprCogpfC0h+tEMjpTFyhWMTTA8KJtmVMd2tCmAODAobiT5H8DPMCQQjZD/Y aKLF1FszVUHNQXzuk9UEJKYtXHP8fD5+Z8Puqqj4j0YkjmsXQYFXp8kttLNN2n9HVMfL hEtw== X-Gm-Message-State: ALyK8tKHKMBGh6jsmQfQ/NgA7KdPNb+0BkKr1EtrNODUCKYFgs8hPXBK1vhpKv0bSfCNUUJP X-Received: by 10.28.90.65 with SMTP id o62mr10500674wmb.16.1465204634486; Mon, 06 Jun 2016 02:17:14 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id e8sm13232874wma.2.2016.06.06.02.17.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 02:17:13 -0700 (PDT) From: Thomas Monjalon To: "Mcnamara, John" Cc: dev@dpdk.org, Christian Ehrhardt , Markos Chandras , Panu Matilainen Date: Fri, 03 Jun 2016 18:05:15 +0200 Message-ID: <2142445.VVEujR2XLL@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 09:17:14 -0000 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? 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. > 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)? [...] > 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. > 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. [...] > 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 I'm sure there will be more validation on the field or from contributors. [...] > The LTS guidelines shall be reviewed after 1 year to adjust for any experiences > from LTS maintainership. Yes seems very reasonnable. Thanks