From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MlkO2-0000D9-PR for qemu-devel@nongnu.org; Thu, 10 Sep 2009 10:12:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MlkNx-0000BO-OA for qemu-devel@nongnu.org; Thu, 10 Sep 2009 10:12:33 -0400 Received: from [199.232.76.173] (port=46357 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlkNx-0000B5-BO for qemu-devel@nongnu.org; Thu, 10 Sep 2009 10:12:29 -0400 Received: from mx20.gnu.org ([199.232.41.8]:24176) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MlkNv-0000fN-K8 for qemu-devel@nongnu.org; Thu, 10 Sep 2009 10:12:28 -0400 Received: from qw-out-1920.google.com ([74.125.92.148]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MlkNu-0006uS-Tb for qemu-devel@nongnu.org; Thu, 10 Sep 2009 10:12:27 -0400 Received: by qw-out-1920.google.com with SMTP id 5so43338qwc.4 for ; Thu, 10 Sep 2009 07:12:24 -0700 (PDT) Message-ID: <4AA90945.3000709@codemonkey.ws> Date: Thu, 10 Sep 2009 09:12:21 -0500 From: Anthony Liguori 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> <20090910140413.GA28534@amit-x200.redhat.com> In-Reply-To: <20090910140413.GA28534@amit-x200.redhat.com> 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: Amit Shah Cc: Bernhard Kauer , qemu-devel@nongnu.org Amit Shah wrote: > On (Thu) Sep 10 2009 [08:56:34], Anthony Liguori wrote: > >>> If there'd be a daemon sending a mail saying the patch is in some >>> staging queue it'll reduce everyone's effort. Such extra mails >>> definitely aren't a problem. If it's later reverted because of any kind >>> of failure, again a polite mail wouldn't hurt. >>> >>> >> The problem is patch volume. We often see hundreds of patches a day. >> If typing a mail for each patch takes 2 minutes, that's potentially >> hours spent just on sending these mails. >> > > How about a bot that goes through your mailbox (or your git queue) and > sends the email? One reply-to-all email for each unique hash you have > against qemu-master? > Yeah, it's easy to do that for initial commit. Git lacks the hooks to do it for when you drop something via git rebase though. A few weeks ago, a bunch of commits slipped through with Message-Id tags. That was my attempt to add some smarts to git to allow for this but it didn't work out the way I wanted it to. > ... and store the commit ids and subject in some file. When you rebase > and that particular commit-id + subject combination is not present, an > auto-email can be triggered > 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 >> Usually, if I remove a patch from the queue because something is wrong >> with it, I send out an email explaining what is wrong. >> > > ... but this is simpler and more efficient also because you can give the > reason along with the email rather than people mailing you later asking > why the patch was dropped. > 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. Regards, Anthony Liguori