Re: RFC: change to 6 months release cycle

[Juergen Gross <jgross@suse.com>]

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.


Juergen