Re: [Qemu-devel] We need more reviewers/maintainers!!

[Stefan Weil <sw@weilnetz.de>]

Am 12.03.2012 21:27, schrieb Anthony Liguori:
> On 03/12/2012 03:12 PM, Stefan Weil wrote:
>> Am 12.03.2012 18:06, schrieb Stefano Stabellini:
>>> Hi all,
>>> I don't mean to steer any controversy or start any flame wars here, but
>>> rather I want to point out a problem in the QEMU Community that is
>>> preventing us and other people from having a good experience working
>>> upstream with QEMU. Call it constructive criticism.
>>>
>>> Patches are being posted to the list that don't get any reviews at all.
>>> Other patches get reviewed the first time, then once they are reposted
>>> they don't get any other reviews or acked-by or reviewed-by.
>>>
>>> As a whole it takes biblical times to get through the QEMU review
>>> process. I wonder how any commercial company with deadlines would be 
>>> able
>>> to cope with them. Even the Xen Community, that is far from a 
>>> commercial
>>> company, is having difficulties with them and now upstream QEMU is at
>>> risk of missing the 4.2 release target.
>>>
>>>
>>> We need more people reviewing patches. And we need more maintainers.
>>>
>>>
>>> Anthony Liguori is still the maintainer for many areas within QEMU, and
>>> he is clearly too busy for that. We need more people helping him review
>>> patches for source files like savevm.c and vl.c.
>>>
>>> I believe in leading by example, so Anthony Perard and I will try to
>>> review more patch series, even outside Xen support in QEMU, starting
>>> from now.
>>> I hope more people will start to do the same to the point that it will
>>> get natural to add more names and email addresses to the MAINTAINERS
>>> file.
>>>
>>> I hope that other people will recognize that this is a problem and be
>>> willing to step up to find a solution.
>>>
>>> Thanks,
>>>
>>> Stefano
>>
>> I agree that more maintainers would be good, but we also need
>> more people with commit rights.
>
> I disagree strongly.  Having multiple pushers makes things difficult 
> and encourages people to push without testing.  Part of what makes 
> pushing take longer than it should today is that my test cycle takes 
> at least 1-2 hours and it's not uncommon to have to go through 3-4 
> cycles of rebasing before being able to push.
>
>> Why? There a many examples of
>> urgent patches (= patches which fix broken builds) which take
>> several days even when they were reviewed before they finally
>> are committed.
>
> Can you be specific?  I think you really mean, "urgent patches for 
> Win32" but since you're the win32 maintainer, it's on you to do a PULL 
> request.

Please use w32 (win32 is a registered trademark of Microsoft,
and there are also other reasons why I try to avoid it).

I don't mean w32 patches only. The last build break was for ppc hosts
(e04b28996110bd6acfc059e9f2c8c5aba5119a46, it took more than 5 days),
but I remember also situations were x86 was broken more than
a day.

A selection of older patches which fixed build and the time it took
from creation to commit:

6148b23d69444a300710db0c53f6c53b7f3c8067 (kvm ppcm 3 days)
1ecf47bf0a091700e45f1b7d1f5ad85abc0acd22 (w32, 2 days)
aea317aaa5d92ee8789f976ccf105be67d956f5e (0 days, patch written by Anthony)
be85c90b74f56dca51782fa3080fcdf88593e045 (1 day)
3439eec34f8c0ded2ff08da08b058804382a3736 (0 days)
3a26360d1df3c3519a45636ec2189429d3df0ecb (0 days, patch written by Anthony)
98efaf75282a96ffbe2914f79a9f5cb736a03db4 (ppc, 7 days)
d20423788e3a3d5f6a2aad8315779bf3f952ca36 (3 days)
8e72506e20d9e606783de1cdb8d60dd9b9241e30 (0 days)
f44cc4852a04c0423780e115b935e201aaf3384e (3 days)

Cheers,

Stefan W.