From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7CdR-0008MH-MG for qemu-devel@nongnu.org; Mon, 12 Mar 2012 17:18:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7Cd5-0001Y3-PX for qemu-devel@nongnu.org; Mon, 12 Mar 2012 17:18:29 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:40430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7Cd5-0001Xd-GV for qemu-devel@nongnu.org; Mon, 12 Mar 2012 17:18:07 -0400 Received: by dadp14 with SMTP id p14so6943739dad.4 for ; Mon, 12 Mar 2012 14:18:05 -0700 (PDT) Message-ID: <4F5E6809.1000405@codemonkey.ws> Date: Mon, 12 Mar 2012 16:18:01 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4F5E58BE.6040808@weilnetz.de> <4F5E5C49.6060900@codemonkey.ws> <4F5E66A8.5050308@weilnetz.de> In-Reply-To: <4F5E66A8.5050308@weilnetz.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] We need more reviewers/maintainers!! List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: qemu-devel@nongnu.org, Stefano Stabellini 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. >