|
[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 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |