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

Re: [Xen-devel] [Hackathon Minutes] Xen 4.4 Planning

On 13/06/13 15:22, Jan Beulich wrote:
On 13.06.13 at 16:00, Lars Kurth <lars.kurth@xxxxxxx> wrote:
= Release Models that work well =
There was a brief discussion on two different release models
* Train leaves the station (Linux)
* Release when ready (Debian)

== Stefano's Proposal ==
We should aim to reduce the release cycle to 4 months (or maybe 6 months
as an intermediate step) from the current 9 months. A 4 months relase
cycle should help accelerate development and lead to fewer patches being
queued up. The implications are that we would have to operate a 2-3
weeks merge window.

To do this, we would need to resolve a number of issues
* It is likely that code reviews for such a short merge window would
become a bottleneck. We are not sure whether this would be a major issue
: the review bandwith would depend on the patches submitted (and their
* [I can't remember who raised this] The concern was raised that we
would not have enough x86 Xen reviewers got a 2-3 weeks merge window
* [Konrad] Stated that in PVOPS for Linux contributions we don't have a
review bottleneck, but we should make sure that the Xen and PVOPS/Linux
merge window don't overlap (as this would require the same set of people
to review patches in two projects)
* The rest of the time (approx 3 months) would be used for stabilizing
the release
* If we had a more extensive testing framework, and thus better testing,
we could tighten the RC period (making this happen is also being
discussed by the Advisory Board)

Additional conerns raised:
* [Matt Wilson]: if we had shorter merge windows, there is a risk that
we would end up with unnused code (uncompleted features) in mainline.
Something which we'd rather not have
* [I can't remember who raised this] But we already have a buffer via
staging : we could make more use of this

[Conclusion] We aLL agreed, that a release cycle of less than 9 months
is desirable. Maybe we can go to 6 months for Xen 4.4 (before being more
I sincerely hope that we won't switch to this (Linux) model. Having
just a couple of weeks to get new code added means that everyone
halfway deeply involved in the development will have to permanently
carry a huge bag of patches. I'm thinking this is painful enough
already for the freeze periods we currently have.

This would be much less painful if you used git branches. :-)

Seriously, check out stackgit -- it will make keeping track of all those patches, and of rebasing them, much much easier. (Not to mention make it easier to send them, share them, merge them, &c.)

That implies, however, that with an approximate freeze period of 3
months, shortening the release cycle to or even below 6 months is
going to be an issue. From the summary above I didn't really get
what's wrong with the current 9 month cycle, which - perhaps for
the first time since I joined the project - it seems like we can actually
meet with 4.3.

The problem with the current cycle I think is that if you miss getting a feature into this release, it's going to be a full year and a half until the next release. This means that there is increased pressure to try to "shove things in" at the last minute, and to ask for feature freeze exceptions. If I was sure that 4.4 would be another 9-month cycle, I would have pushed much harder to make USB hot-plug support a blocker, for example. That in turn causes less review, longer code freezes, and so on.

If there's a 4-month cadence, then if you miss one release, it's only another 4 months until the next release; not a big deal to wait.

The only option I would see is to branch before RC1, thus keeping
the development tree open irrespective of the ongoing release. Of
course that's having the drawback of possibly/likely pulling away
the attention of some of us from the being released branch (I would
be very surprised if I wouldn't end up among those "some").

Ian C in fact proposed that this (doing bug-fixing, development, and review at the same time) might not be a bad thing. It would make the "freeze" longer, but if we had shorter release cycles, and if people could still get review time and maybe even items merged, then having a long freeze might not actually be all that terrible.

Branching before RC1 would essentially be similar to the Linux model of "maintainers having their own branches", except that we'd just have one branch. Given that there are only a handful of developers compared to Linux, that might not be such a bad model to start with.

Then there wouldn't actually be a merge window per se -- we'd just fork off a branch every N months and start stabilizing it.


Xen-devel mailing list



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