qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] [RESEND2] Qemu unmaintained?


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] [RESEND2] Qemu unmaintained?
Date: Sun, 13 Sep 2009 18:49:42 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3

On 09/10/2009 10:31 PM, Anthony Liguori wrote:
Avi Kivity wrote:
For qemu.git I'd agree since it's undergoing a lot of churn. Unfortunately it also feeds qemu-kvm.git which I try very hard to keep regression-free (and finding and fixing regressions during a merge is quite horrible), so I'd really appreciate it if qemu.git quality didn't deteriorate.

Or more accurately, you'd prefer if there were no bugs in qemu so that you only had to deal with the bugs that were introduced in qemu-kvm.

Yes.  Anyone who pulls qemu.git and develops or uses it would agree.


That would be nice for you of course :-) But it's unrealistic to compare the two. $ git log --since='1 Month ago' --no-merges qemu-kvm/master --committer='Avi Kivity' --pretty=format:'%an' | wc -l
5
$ git log --since='1 Month ago' --no-merges qemu-kvm/master --committer='Marcelo Tosatti' --pretty=format:'%an' | wc -l
5

$ git log --since='1 Month ago' --no-merges origin/master --committer='Anthony Liguori' --pretty=format:'%an' | wc -l
251

So there are going to be at least 25x more regressions introduced from upstream qemu than what are introduced in qemu-kvm.

Well, if we define a regression as something that blocks me from pushing (kvm-autotest), then both numbers are zero. Of course qemu.git is not run purely for my enjoyment, but a large number of patches are targeted at qemu-kvm.git. Further, the tests that I run (installing and booting some popular OSes) are really the basic minimum functionality, nothing fancy there.


(and we're quite far from catching every regression btw).

Anthony, how long are your test cycles?

Depends on the number of regressions. I can usually get through testing in 4-5 hours when everything works. Everything usually doesn't work though.

We definitely need to improve this and the 80% reject rate. Can you start being a lot noisier about rejects? that will at least give some visibility into the problem.

--
error compiling committee.c: too many arguments to function





reply via email to

[Prev in Thread] Current Thread [Next in Thread]