Re: [Xen-devel] [RFC] Tweaking the release process for Xen 4.6

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, Feb 10, 2015 at 10:04 AM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> Hi, all
>
> With Xen 4.5 released on Jan 14 and the open of Xen 4.6 (commit
> 0082626f35, Jan 6), we are now one month into 4.6 development window.
>
> This is an email to kick off a discussion with regard to our release
> process.The goal is to create a smoother workflow for everyone involved.
> Emails to track features will be sent separately.
>
> # Xen 4.5 time frame retrospect
>
> Xen 4.5 time frame is as followed.
>
>   Development start: 21 Feb  2014
>   Feature freeze:    24 Sept 2014
>   RC 1:              24 Oct  2014
>   RC 2:              11 Nov  2014
>   RC 3:              3  Dec  2014
>   RC 4:              15 Dec  2014
>   Release:           14 Jan  2015
>
> Counting from the point that we forked the tree, it took ~11 months to
> ship 4.5. The time spent on development was 7 months (Feb 21 to Sept
> 24), and the time spent on freeze was ~4 months (Sept 24 to Jan 6).
>
> The good thing was that code quality was ensured, the downside was that
> such long freeze made upstreaming new features harder for contributors
> -- they need to rush to get their features at least posted in
> development window, then argue for whether it's OK to get in after soft
> freeze; Otherwise  they risk waiting several more months.
>
> # Scrapping soft freeze
>
> I think existing model (development + freeze) works well in general,
> but it would be better if we can shorten the time frame a bit, or try
> harder to stick to the 9 months promise.
>
> I would like to propose a tweak: scrap the soft freeze. The soft freeze
> is used to allow features posted during development window to get merged
> in time for a certain release. However this practice leads to longer
> freeze period (new features means more testing, hence longer freeze).
>
> If we scrap the soft freeze, there are several pros:
>
> 1. We only need to harden existing features in freeze. That would
>    probably shorten the time needed for freeze, or at least keep
>    everything within 3 months time frame.
>
> 2. Contributors with big features to upstream would not need to rebase
>    aggressively because they don't need to worry about features that
>    go in between soft freeze and hard freeze.
>
> 3. Contributors can accelerate their upstreaming effort by benefiting
>    from the possible shorter freeze time.
>
> I think this tweaked process can help make the development flow
> smoother. We release in a more timely manner and contributors have less
> work to do.
>
> The cons are of course we have shorter time in freeze and lead to
> possible less harden code. But I don't really see that as a big
> issue, given that we a) we still set aside 3 months for it, b) we
> only need to harden existing code.
>
> What contributors need to do with this changed process: develop and
> upstream features as usual in development window, but no more arguing
> whether a feature should go in after freeze.
>
> What maintainers / committers need to do with this changed process:
> "business as usual" during development window, no more new feature
> after freeze, only bug fixes can go in.
>
> # Proposed Xen 4.6 time frame
>
> With the above proposal in mind, here is my proposed time frame for
> Xen 4.6 release:
>
>   Development start: 6  Jan 2015
>   Feature freeze:    10 Jul 2015
>   Release date:      9  Oct 2015 (could release earlier)
>
> Note that the release date is not a goal. It is more like a deadline
> we try to keep up with. We might be well able to release earlier if
> everything is in good shape.
>
> Any thought on this tweaked process? Comments are welcome.

I think it's certainly worth a try.

 -George

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