Re: [Xen-devel] RFC: change to 6 months release cycle

[Juergen Gross <jgross@xxxxxxxx>]

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel