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

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/12/2012 04:12 PM, Stefan Weil wrote:
> 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)

So both of these platforms have maintainers that can do PULL requests for issues 
like this.

> aea317aaa5d92ee8789f976ccf105be67d956f5e (0 days, patch written by Anthony)
> be85c90b74f56dca51782fa3080fcdf88593e045 (1 day)
> 3439eec34f8c0ded2ff08da08b058804382a3736 (0 days)
> 3a26360d1df3c3519a45636ec2189429d3df0ecb (0 days, patch written by Anthony)
> 98efaf75282a96ffbe2914f79a9f5cb736a03db4 (ppc, 7 days)

I cannot easily test patches for !x86 host so it really needs to come through a 
pull request.

> d20423788e3a3d5f6a2aad8315779bf3f952ca36 (3 days)

We've had some issues with hw/9pfs but I think we've got this covered now.

> 8e72506e20d9e606783de1cdb8d60dd9b9241e30 (0 days)
> f44cc4852a04c0423780e115b935e201aaf3384e (3 days)

Without searching the list, I think this was a BSD specific build failure.

Not ideal, but I'm pretty happy with this numbers.

Regards,

Anthony Liguori

>
> Cheers,
>
> Stefan W.
>