[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.