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
