Re: RFC: change to 6 months release cycle

[Andrew Cooper <andrew.cooper3@citrix.com>]

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.

~Andrew