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

[Stefan Weil]

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.