[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 22:03, Alex Bligh wrote:

--On 13 June 2013 15:00:46 +0100 Lars Kurth <lars.kurth@xxxxxxx> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.