From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MllNx-0003EB-HV for qemu-devel@nongnu.org; Thu, 10 Sep 2009 11:16:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MllNs-0003Dr-4D for qemu-devel@nongnu.org; Thu, 10 Sep 2009 11:16:32 -0400 Received: from [199.232.76.173] (port=57056 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MllNr-0003Do-Ui for qemu-devel@nongnu.org; Thu, 10 Sep 2009 11:16:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13661) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MllNr-0005xp-DL for qemu-devel@nongnu.org; Thu, 10 Sep 2009 11:16:27 -0400 Date: Thu, 10 Sep 2009 20:45:56 +0530 From: Amit Shah Subject: Re: [Qemu-devel] [PATCH] [RESEND2] Qemu unmaintained? Message-ID: <20090910151556.GC28534@amit-x200.redhat.com> 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> <20090910140413.GA28534@amit-x200.redhat.com> <4AA90945.3000709@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AA90945.3000709@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Bernhard Kauer , qemu-devel@nongnu.org On (Thu) Sep 10 2009 [09:12:21], Anthony Liguori wrote: > > Yeah, I tried that without a lot of success. Basically, my work flow is > the following: > > 1) Mail client filters things that look like patches into a folder > 2) I do a once through to remove obvious dups or non-patches > 3) I have some scripts that pull patches into an mbox format. They are > smart about identifying threads and trying to find a sane sort order. > 4) I have more scripts that let me split the mbox into smaller mboxes. > This is because git am is not very forgiving and having to do a git am > --abort can lead to a lot of wasted effort if the mbox has 100+ patches > 5) I git am the smaller mboxes into staging > 6) I push to staging > 7) I do a build check, and fix errors, and push to staging > 8) I start the testing cycle, removing patches based on testing results > and pushing to staging > 9) I manually review each patch that's survived testing > 10) I do final build/test, then push to master Obviously there's a lot of manual intervention and can get you overloaded. But if some developer knows that his patch is in some queue or getting some consideration, he'll rest easier than to check if his patch has made it either to master or to some staging queue somewhere. If it can't be automated, it sadly has to drop back to manual acking. > And commit mails are sent whenever something goes to master. So someone > should get a mail when a patch goes to master or when I reject it. To > me, the area to optimize is reducing the time things are spent in > staging. I don't think people really need visibility into staging. Absolutely. I think the trend has been anywhere from 2 to 4 weeks for patches landing on the list to the master tree. Also, this results in delays for important patches to get to the master tree because they're delayed behind a huge pile of other patches. Avi has mentioned this before but I don't know if there was any plan to address it. Amit