From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: RFC: change to 6 months release cycle Date: Fri, 2 Oct 2015 19:52:30 +0200 Message-ID: <560EC45E.4080605@suse.com> References: <20151002174356.GA3577@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" 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 1Zi4VU-0001qN-IH for xen-devel@lists.xenproject.org; Fri, 02 Oct 2015 17:52:32 +0000 In-Reply-To: <20151002174356.GA3577@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 , xen-devel@lists.xenproject.org Cc: Lars Kurth List-Id: xen-devel@lists.xenproject.org On 10/02/2015 07:43 PM, Wei Liu wrote: > Hi all > > As I understand it in the past there were discussions on release every > 6 months. I would like to revisit this topic. > > # Rationale for a shorter release cycle > > The current 9 months cadence is too long. That create at least two > problems for us. > > The first problem is that Xen delivers features much slower than other > projects. Linux kernel releases every 3 months. QEMU releases every 4 > months. They deliver new features at a much higher frequency. > > The second problem is that the opportunity cost for vendors to miss a > release is very high. When combined with the freeze exception scheme, > tension quickly builds up around cut-off point, which creates > frictions and frustrations for both contributors and maintainers. This > is detrimental to the project in the long run. > > Having a shorter release cycle plus some other measures seem to make > sense. > > The main objection from previous discussion seems to be that "shorter > release cycle creates burdens for downstream projects". I couldn't > quite get the idea, but I think we can figure out a way to sort that > out once we know what exactly the burdens are. > > A side note is that if we really go down this route we need to stick > with it for a few releases to let people get used to it. Any change to > the release process is going to cause some issues. > > # Proposed release cycle > > Aim for 6 months release cycle -- 4 months development period, 2 > months hardening period. Make two releases per year. > > Fixed hard cut-off date, no more freeze exception. Arrange RCs > immediately after cut-off. > > Take into account holiday seasons in US, Europe and China, the two > cut-off dates are the Fridays in which that last day of March and > September are in. > > Targeted release date is two months after cut-off date. Still, we pick > a Friday using the same rule. We can also release a bit earlier if > everything goes well. If we somehow fail to release on time, we eat > into next development cycle. The next cut-off date will still be > fixed. > > With the proposed scheme, the dates will be: > > - 4.7 cut-off date: April 1, 2016 > - 4.7 release date: June 1, 2016 > > - 4.8 cut-off date: September 30, 2016 > - 4.8 release date: December 2, 2016 > > - 4.9 cut-off date: March 31, 2017 > - 4.9 release date: June 2, 2017 > > and it goes on. > > # Feasibility analysis > > Xen 4.6 is almost out of the door. I think it's convenient to use it as one > data point about how we can achieve the proposed plan. > > Xen 4.6 release time line broken down: > > - developemnt: 6 months > - consideration for freeze exception: 1 week > - applying patches with free exception: 1 week > - fix major bugs: 2 weeks > - RCs: every 1 to 2 weeks > > We aimed for a 9 months release cycle. That means we have 3 months for > stabilisation and RCs. > > Note that the 2 weeks used to fix bugs were mostly for bugs introduced > during free exception. > > The riddance of freeze exception saves us at least the first 2 weeks. > And because there are less changes due to shorter development cycle and > no freeze exception, there are probably less bugs, which means we can > potentially save another week or two. So the 6 months time line is > realistic to achieve. Expecting less bugs due to a shorter development cycle is strange. I'd expect more bugs as large features have less time to be stabilized. Or are you expecting only small features in the future? I don't hope so. Juergen