Re: [Hackathon Minutes] Xen 4.4 Planning

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

On 13/06/13 22:03, Alex Bligh wrote:
>
>
> --On 13 June 2013 15:00:46 +0100 Lars Kurth <lars.kurth@xen.org> wrote:
>
>> 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.
>
> Disclaimer: I don't claim to be a xen developer, despite writing a few
> patches. But we are a heavy libxl API user. This perspective may or may
> not be useful from a 'consumer of your development' perspective. Delete
> or ignore if not.
>
> The thing we like the least about Xen is (was?), stuff breaking between
> major releases. If you have to drop 90% of your new features in order
> not to break stuff, please do just that. Xen 3.x -> Xen 4.1 (we mostly
> skipped 4.0) was a huge change, requiring a lot of rewriting. Xen 4.1
> to Xen 4.2 was far, far worse; had we not needed it to support
> qemu-upstream, we'd have probably stuck with 4.1. We talk to 4 
> hypervisors,
> and have never had this difficulty with any other hypervisor. You can
> imagine our joy when we found we could compile against 4.3 (we haven't
> tried running yet) without a single line code changed. Please, please,
> keep it like this. If we can also run unchanged against 4.3, this will
> be even better.

I think we've been aware of this for some time, and have only in the 
last few years really put an effort into sorting out some of these 
issues.  Having libxl as a library, with an API compatibility promise, 
was one step in that direction.  Another step in that was having a 
better testing infrastructure, which has helped a great deal.

If it's any comfort, the problems you had upgrading 3.x->4.1 and 
4.1->4.2 have been shared by the Citrix XenServer team, so there's a lot 
of desire to make the process better.

The testing of the upstream Xen is still really lacking, however -- this 
is a known problem, and is actually being discussed at the moment by the 
Linux Foundation project members.  At the moment, the real hard-core 
testing of Xen happens by the downstream users -- XenServer, OracleVM, 
SuSE, plus cloud vendors (including you) -- but this is a rather 
wasteful duplication of effort.  Having a more thorough testing 
infrastructure and set of test cases for upstream Xen would mean the 
standard Xen releases were of much higher quality; this would benefit 
everyone.

In any case, thanks for sharing your thoughts -- it's useful to have 
your perspective.  We'll have to keep these in mind going forward.

  -George