From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K3ZmY-0004un-CU for qemu-devel@nongnu.org; Tue, 03 Jun 2008 12:54:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K3ZmV-0004ts-LU for qemu-devel@nongnu.org; Tue, 03 Jun 2008 12:54:45 -0400 Received: from [199.232.76.173] (port=41502 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K3ZmV-0004tp-Hi for qemu-devel@nongnu.org; Tue, 03 Jun 2008 12:54:43 -0400 Received: from an-out-0708.google.com ([209.85.132.245]:13186) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K3ZmU-000408-RZ for qemu-devel@nongnu.org; Tue, 03 Jun 2008 12:54:43 -0400 Received: by an-out-0708.google.com with SMTP id d18so637408and.130 for ; Tue, 03 Jun 2008 09:54:41 -0700 (PDT) Message-ID: <48457741.9070302@codemonkey.ws> Date: Tue, 03 Jun 2008 11:54:25 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] An organizational suggestion References: <193307.64140.qm@web57014.mail.re3.yahoo.com> <18501.20210.209142.106241@mariner.uk.xensource.com> <200806031535.40996.paul@codesourcery.com> <18501.23962.985598.92661@mariner.uk.xensource.com> <20080603151729.GB1222@shareable.org> <18501.25321.636839.502256@mariner.uk.xensource.com> In-Reply-To: <18501.25321.636839.502256@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Ian Jackson wrote: > Jamie Lokier writes ("Re: [Qemu-devel] An organizational suggestion"): > >> It's the Linus Torvalds school of flow control. If you don't get a >> reply, try again. >> > > I see. That seems rather rude to me, so I don't do it. Am I really > supposed to keep a list of my outstanding patches and retransmit them > like some kind of bandwidth-hogging peer-to-peer application ? > The DCO process can really help here. The simple fact is that most of the committers to QEMU are not paid to be full-time maintainers. As such, their time is limited. There is a lot of noise on qemu-devel (this thread being a good example ;-)). If you review a patch, and are happy with it, offer an Acked-by. When comitters go through reviewing patches to commit, it makes it much easier for them to determine whether a patch should be committed or not. > If everyone did that, then the number of patches accepted would go > down rather than up, surely ? Because everyone would be spending > their time wading through all these resends, rather than paying > attention to the content. > Try marking the subject with [RESEND]. Quite a lot of projects require patches to be resent. In fact, in the early days of Xen, this was often the case. [RESEND] tends to be a polite way to help maintainers be more responsive too. > Also - implicit in your comment that it's a form of `flow control' is > that it's caused by a lack of upstream capacity. I think that part is > very true. We do have a lack of capacity, which can be solved in this > case by adding one or more people I think. > There are already a lot of committers in QEMU. There are 9 people with commit access to QEMU. There is only 1 person with commit access to KVM and that includes a full copy of QEMU. What's needed is someone to take the time, on a day-by-day basis, to review patches, and queue them. Magnus posted a list of outstanding patches a while ago, I think that's the right approach. I'll spend some time today to try and collect outstanding patches. Regards, Anthony Liguori > Qemu is not a very large project in the grand scheme of things, and we > can hopefully avoid the kind of very cumbersome and heavyweight > processes which surround the Linux kernel. > > Ian. > > >