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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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 
> complexity)
> * [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 
> aggressive).

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.

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

Jan


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