Re: [Hackathon Minutes] Xen 4.4 Planning

[George Dunlap <george.dunlap@eu.citrix.com>]

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
>> complexity)
> 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
> cycle).
>
> 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.

  -George