Re: [Hackathon Minutes] Xen 4.4 Planning

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

On 13/06/13 15:22, Jan Beulich wrote:
>>>> On 13.06.13 at 16:00, Lars Kurth <lars.kurth@xen.org> 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.

This would be much less painful if you used git branches. :-)

Seriously, check out stackgit -- it will make keeping track of all those 
patches, and of rebasing them, much much easier.  (Not to mention make 
it easier to send them, share them, merge them, &c.)

> 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 problem with the current cycle I think is that if you miss getting a 
feature into this release, it's going to be a full year and a half until 
the next release.  This means that there is increased pressure to try to 
"shove things in" at the last minute, and to ask for feature freeze 
exceptions.  If I was sure that 4.4 would be another 9-month cycle, I 
would have pushed much harder to make USB hot-plug support a blocker, 
for example.  That in turn causes less review, longer code freezes, and 
so on.

If there's a 4-month cadence, then if you miss one release, it's only 
another 4 months until the next release; not a big deal to wait.

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

Ian C in fact proposed that this (doing bug-fixing, development, and 
review at the same time) might not be a bad thing.  It would make the 
"freeze" longer, but if we had shorter release cycles, and if people 
could still get review time and maybe even items merged, then having a 
long freeze might not actually be all that terrible.

Branching before RC1 would essentially be similar to the Linux model of 
"maintainers having their own branches", except that we'd just have one 
branch.  Given that there are only a handful of developers compared to 
Linux, that might not be such a bad model to start with.

Then there wouldn't actually be a merge window per se -- we'd just fork 
off a branch every N months and start stabilizing it.

  -George