From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MlmcK-0006EZ-L1 for qemu-devel@nongnu.org; Thu, 10 Sep 2009 12:35:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MlmcF-0006CD-Lb for qemu-devel@nongnu.org; Thu, 10 Sep 2009 12:35:28 -0400 Received: from [199.232.76.173] (port=54828 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlmcF-0006C5-FO for qemu-devel@nongnu.org; Thu, 10 Sep 2009 12:35:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28528) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MlmcE-00056x-TJ for qemu-devel@nongnu.org; Thu, 10 Sep 2009 12:35:23 -0400 Message-ID: <4AA92ADF.80003@redhat.com> Date: Thu, 10 Sep 2009 19:35:43 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] [RESEND2] Qemu unmaintained? References: <20090902074905.GB25711@chrom.inf.tu-dresden.de> <20090909121817.GA21997@chrom.inf.tu-dresden.de> <4AA7A6EC.10907@codemonkey.ws> <20090910070336.GD3351@amit-x200.redhat.com> <4AA90592.7080100@codemonkey.ws> <4AA90F7F.2030709@redhat.com> <4AA92122.3050103@codemonkey.ws> <4AA924AE.8060807@redhat.com> <4AA927D8.7000900@codemonkey.ws> In-Reply-To: <4AA927D8.7000900@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Amit Shah , Mark McLoughlin , Bernhard Kauer , qemu-devel@nongnu.org On 09/10/2009 07:22 PM, Anthony Liguori wrote: >> You certainly shouldn't ack patches you don't commit! > > > But most spend time in staging. What's the percentage of patches that make it to master? For me it's >90%. If it's too low we nned to fix that. > > Acking patches that go to master, that's perfectly fine to do. I think that's too late, especially as it often takes a week for master to be pushed. To a submitter, an ack means "no further action is required from you at this time" and it's good to provide it as early as possible. > The qemu-commits list does that and should CC the author directly so > this should be happening. It's too late, and doesn't help others who have an interest in the patch. > It's acking things that go into staging that I think would be > difficult and not necessarily productive. That is what I do and it doesn't seem to be troublesome. If I drop a patch from a queue I explicitly unack it. > >>> This is goofy and is caused by improper patch submission. But when >>> people quote email threads in a commit message, I don't remove >>> them. It don't see it as a problem. >> >> From long experience, most commit messages need to be edited. People >> rarely write commit messages that can be understood a year later, and >> they don't know how 'git am' works. > > I don't like editing patches. I think it's unfair to the submitter to > change their patch underneath of them. I'd suggest providing feedback > on the list to people who write bad commit messages and ask them to > write better ones. I try to limit the changes I make to resolving > merge conflicts. Editing the commit log is not changing the patch. I doubt you'll be able to get better commit messages - submitters have more immediate perspectives than maintainers (should have). I always try to make the log make sense a year from now (the code may change, but the commit log won't). Unfairly picking on Mark (who usually writes truly excellent changelogs, but this one is such a gem): > Subject: [Qemu-devel] [PATCH 01/19] Suppress more more kraxelism > > Let's kick off this series with some of the more critical fixes. > > Signed-off-by: Mark McLoughlin > What would you be thinking hunting the commit log for some change and coming up with this? (Mark, apologies for picking on you, it's truly unfair of me, but I can't help it) -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.