Re: [Qemu-devel] [PATCH] [RESEND2] Qemu unmaintained?

[Anthony Liguori]

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