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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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.

Wei.

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