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

[Alex Bligh <alex@xxxxxxxxxxx>]

Jan,

--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
release.

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

--
Alex Bligh

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