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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-06-13 at 15:52 +0100, George Dunlap wrote:
> 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.

Agreed. And as you say in your other mail 2 weeks dev + 3 months
stabilisation isn't a good fit for us, something more like 3 months dev
and 1 month stabilisation is a much better fit and avoids most of the
issues I was thinking of.

> > 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.

Agreed.

Ian.





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