Re: [Qemu-devel] Re: commit rules for common git tree

[Michael S. Tsirkin]

On Mon, Dec 28, 2009 at 10:58:32AM +0200, Avi Kivity wrote:
> On 12/28/2009 12:52 AM, Anthony Liguori wrote:
>>
>> As a reviewer, you can read qemu-commits to see when something has  
>> been committed.
>>
>> I have the same problem fwiw.  I don't read qemu-commits because I  
>> always look at the contents of origin when I fetch from it to see what  
>> others are doing.  Practically speaking, to really review patches, I  
>> think you have to follow master to see what's changing.
>>
>> I'm open to creative ideas, but my main concern is that when there's a  
>> push in one day of 50 unique patches (which happens), that's a big  
>> flood of email to various threads which gets annoying to sift through.
>>
>> I don't it's a huge burder to just read another mailing list.
>
> There are two issues with qemu-commits (neglecting that it's broken for  
> the moment):
>
> - it sends email when a patch is pushed, not when it is committed.  This  
> breaks the "I don't have to follow this up anymore" property.
> - it breaks threading.  you see a patch, you have no idea what its  
> status is.  Sure, you can go look for it in git or sift for it in  
> qemu-commits, but it's quite a bit of work, and if it isn't there, you  
> have to go do it again later.
>
> It's busy polling vs event driven, I thought that argument was settled  
> long ago.
>
> wrt 50 unique patches a day. I'd think that's quite rare.  Most patches  
> come in large patch sets.

BTW, that's another argument for avoiding automatic mail: qemu-commits
generates 50 messages for a patchset, human will send 1 message.  If
this is really a huge concern, we could send that "applied thanks" to a
separate list.

> -- 
> error compiling committee.c: too many arguments to function