From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: RFC: change to 6 months release cycle Date: Mon, 5 Oct 2015 12:01:30 +0200 Message-ID: <56124A7A.9070905@suse.com> References: <20151002174356.GA3577@zion.uk.xensource.com> <560EC45E.4080605@suse.com> <560ECB16.1060102@citrix.com> <1444038355.11707.175.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Zj2bY-0005o9-Ib for xen-devel@lists.xenproject.org; Mon, 05 Oct 2015 10:02:48 +0000 In-Reply-To: <1444038355.11707.175.camel@citrix.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: Ian Campbell , Andrew Cooper , Wei Liu , xen-devel@lists.xenproject.org Cc: Lars Kurth List-Id: xen-devel@lists.xenproject.org On 10/05/2015 11:45 AM, Ian Campbell wrote: > On Fri, 2015-10-02 at 19:21 +0100, Andrew Cooper wrote: >> On 02/10/15 18:52, Juergen Gross wrote: >>> 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. >> >> The expectation is that with a shorter release cycle, there will be less >> pressure to push large series in at the last minute, as deferring them >> to the next release comes with a substantially smaller penalty. As a >> result, large series will (hopefully) be better baked when they do get >> accepted. > > Right, essentially this is reducing average the latency between acceptance > of a feature and the release which contains it, hopefully relieving some of > the pressure to get something in right away. > > Obviously anything which would have gone in during the final 3 months of a > 9 month release cycle will now be in the first 3 months of the next one, bu > t there is absolutely no implication on the size of an acceptable feature. Bad example. Anything which would have gone in 3 months before the end of the 9 month cycle will now go in just at the end of the 6 month cycle. The average time a feature is tested before release is about half the release cycle. This will drop from 4.5 months to 3 months (assuming a constant feature rate during a release cycle). I'm not against a shorter cycle, I just wanted to point out a (in my eyes) wrong expectation regarding number of bugs due to the changed release cycle. Juergen