[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:31, Ian Campbell wrote:
On Thu, 2013-06-13 at 15:00 +0100, Lars Kurth wrote:
== 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
If we do end up going for this model then I think we need to also
inherit the principal from Linux that the merge window is for *merging*
and that the code in question should have already been posted and
reviewed *before* the window opens (i.e. in the other 3 months of the

This would be something of a cultural change because at the minute
people seem to assume that a freeze means that development and review
must stop. Personally I don't think that should be the case anyway,
although I appreciate the need to focus peoples attention on the release
as well.

I think these are interdependent: Because we view having a code freeze (and having people with out-of-tree patches) as the exception, we try to keep the code freeze as short as possible; which means prioritizing working on the bugs. If we mixed development, review, and bug fixing, then the code freeze would necessarily be longer, as fixing bugs would be delayed. However, this wouldn't necessarily be a terrible thing if everyone was expecting to keep out-of-tree branches anyway.

I think this is simply a normal part of the "train leaves the station"
model. There will always be stuff which misses, but then there is always
the next train, and the one after that.

Yes -- I think this time we ended up sort of trying to do both; "The train is leaving at X time, what can we fit on before that time?"

Having more frequent trains means less need for trying to match up features with releases, as the impact of slipping one release is much lower.


Xen-devel mailing list



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