From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: RFC: Survey on release cycle Date: Thu, 15 Oct 2015 01:47:53 -0600 Message-ID: <561F764902000078000AB391@prv-mh.provo.novell.com> 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.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZmdGY-0004PA-1a for xen-devel@lists.xenproject.org; Thu, 15 Oct 2015 07:47:58 +0000 In-Reply-To: <20151012173222.GE2421@zion.uk.xensource.com> Content-Disposition: inline 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.liu2@citrix.com Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 12.10.15 at 19:32, wrote: > # 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 (with a tendency towards 0 for the base proposal, i.e. willing to give it a try, but a tendency towards -2 for the sharing of the maintenance burden, as I don't expect much good to come from mixed maintainership of stable branches) > # 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). -1 (with a tendency towards -2, foreseeing non-LTS branches to become "bad children") > # 9 months release cycle + current stable release scheme > > Don't change anything. +1 > # 6 months release cycle + extended security support > > The number of active stable branches remains constant (I think this is > currently 2, implying a reducing from 18 months to 12 months) but the > security support period is extended, such that the final cut off is the > same 36 months (18+18 in the current scheme). So this becomes 12 months of > full support + 24 months of security support. 0 (with a tendency towards -1 when taking on my SUSE hat, as a reduction from 18 to 12 months of ordinary support means an increased amount of patches the various distro versions will have to carry on top of the last stable release from the respective branch) Jan