Re: RFC: change to 6 months release cycle

[Ian Campbell <ian.campbell@citrix.com>]

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.

Ian.