From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: RFC: Survey on release cycle Date: Wed, 14 Oct 2015 11:57:25 +0100 Message-ID: References: <20151012173222.GE2421@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZmJmp-0000Aw-GD for xen-devel@lists.xenproject.org; Wed, 14 Oct 2015 10:59:59 +0000 In-Reply-To: <20151012173222.GE2421@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org On Mon, 12 Oct 2015, Wei Liu wrote: > Hi all > > We've had two separate discussions about release cycles, one for > normal release [0], the other for changes in stable release > maintenance and possible long term supported releases [1]. There were > overwhelming support for having a shorter release cycle from > xen-unstable but we couldn't reach consensus on how to manage stable > releases. > > The details on the current 9 months release cycle and proposed 6 > months release cycle can be found in [0], while the current scheme for > stable releases can be found in [2]. A plethora of arguments can be > found in both [0] and [1], but in the end most if not all of them boil > down to empirical arguments / expectations or just merely different > opinions on the same fact so there wasn't really concrete outcome of > that two threads. > > With the release of 4.6, it's important that we have agreement so that > we can get on with planning next release. > > There are several general options on how to proceed that I summarise > from previous discussions. Note that because there are too many moving > parts I pick some of my preferences as a starting point for the > discussion. I also omit the combination of 9 months release cycle + > LTS scheme because it doesn't look attractive in the first place. > > Please express your preference with -2 (strongly argue against), -1 > (not happy but not against), +1 (happy but won't argue for) and +2 > (happy and argue for). > > # 6 months release cycle + current stable release scheme > > The same stable release scheme applies (18 months full support + 18 > months security fixes). Encourage more people to step up to share the > maintenance burden if necessary. Automate part of the workflow to > maintain stable releases. Write down guideline for maintainers. +1 I think it would be a bit too much work for us, but we could probably cope. However it is still better than what we have now. > # 6 months release cycle + LTS scheme > > Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS > releases receive shorter support. Encourage more people to step up to > share the maintenance burden if necessary. Automate part of the > workflow to maintain stable releases and LTS releases. Write down > guideline for maintainers. > > The length of support hasn't been discussed thoroughly -- but to make > LTS scheme stand out the length of support would be longer than what > we have now (18 + 18). +2 LTSes solve the problem of the load on stable trees maintainers. > # 9 months release cycle + current stable release scheme > > Don't change anything. -2