[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


--On 14 June 2013 09:15:35 +0100 Jan Beulich <JBeulich@xxxxxxxx> wrote:

On 13.06.13 at 23:03, Alex Bligh <alex@xxxxxxxxxxx> wrote:
The thing we like the second least about Xen is how long it seems to take
to get what we count as serious bugs fixed, even in stable releases.

I think applicable bug fixes get applied to the stable branches in
quite timely a manner, at least on the hypervisor side. Hence I
can only assume that you're unhappy with the rate of stable
releases. Yet I don't think we're going to get anywhere near of
the almost weekly stable releases that get done for Linux. As
you also didn't say what expectations you really have, it's hard
to take out anything useful from that complaint.

I obviously miswrote some of this, as it wasn't intended as a complaint,
rather as observation. As with all open source code, the answer to 'it
doesn't work' is (a) try to find out why, and (b) send code. Which
we have on occasions tried to do.

I'm not unhappy with the rate of stable releases, I am/was unhappy about
the quality of stable releases (particularly 4.2). All our testing to
date on 4.3 indicates it's a lot higher quality release, at least
for what we want it for. It's possible that our expectations were
incorrect, because we were using 4.2 to support qemu-upstream dm,
and this was (IIRC) marked as a 'preview' feature; however we were
surprised things like live migrate were missing, and we had several
'killer' bugs. We've not found that on 4.3. Saying that, we've tested
4.3 quite a lot on its own, but not with our agent code, because we've
been trying to get 4.2 working properly first.

We like it even less if we have to find them and fix them.

But isn't that how open source projects work - everyone contributes
and fixes bugs. If you don't want to help fixing bugs, I'm afraid
there's also no good reason for you to complain they don't get fixed.

I should have explicitly added the words 'in stable releases'. We're
perfectly happy to test, find bugs, etc. and indeed contribute fixes
as we have done. However, we shouldn't (in my opinion) be finding these
in stable releases.

By 'serious' I mean basic functionality not working, crashes dom0, etc.

When did we last break Dom0, and not fix it in a timely manner?

Well, the 'fatal crash on Xen4.2 HVM' thread that started on 14 Dec 2012
had the last fix committed on 5 Apr 2013, and I think came out in 4.2.2
on 23 April. Between those points, as far as I'm concerned anything
running with network backed VMs was likely to crash dom0. That's about
half a 9 month release cycle.

The result of this is two-fold. Firstly, we've never (yet) been able to
run a production version of xen which is a standard xen release. We've
always had to maintain our own patches even on 'stable' releases.
Frankly, this is a pain.

But if you don't contribute back your patches, how do you expect
them to get accepted/merged?

We contributed back ALL of our patches. Every one. And we work pretty
hard to get them merged too. The only one that hasn't been merged or
superseded by a better patch is the minideb patch, which I fully
understand why it wasn't merged, and is just packaging.

I'm not complaining you drop my patches on the floor. In fact
I'm not really complaining at all. What I'm pointing out is that
if a 'stable' is released with a nasty bug in, and it takes a while
to find the right solution, it also takes a while to get a point
release out that fixes it. The solution here is not to change the
rate of acceptance of patches into a stable tree, but to ensure
the bugs are caught before they make their way into a stable

Or are you saying that it's _far_
more than occasional that patches from you get entirely lost?


Alex Bligh

Xen-devel mailing list



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