On Wed, 2009-03-04 at 11:08 -0500, Joe Shaw wrote: > Hi, > > On Wed, Mar 4, 2009 at 9:54 AM, Owen Taylor <[email protected]> wrote: > > No cover mail is sent in the simplest case of someone just pushing > > series of commits at once with no merge or other complications involved. > > It's possible that the numbering should be left out as well. Though it > > helps with the current misordering. > > Ah, ok. Yeah, I'm not sure the numbering buys much, misordering > notwithstanding. > > >> At least one email (for gnome-bluetooth) had broken metadata: > >> > >> * [no subject], Unknown > > > > Looks at that mail in detail - it's an svn commit mail. :-) > > Yeah, but that doesn't explain why the email has a git-style subject? > Is something being trampled?
Looks like a mhonarc bug actually (or actually more likely a bug in our script that run mhonarc); what happened was that the commit that start with http://mail.gnome.org/archives/svn-commits-list/2009-March/msg00926.html Had a line: "From the properties to common/" The "From" in the first column caused the mail to be broken into two pieces in the archive. It's in one piece as delivered to me, which is why I blame our archiver. (I'm never really sure who is supposed to be responsible for turning From into >From and back, or when that is necessary...) The problem won't occur with git since I add " " to the start of all lines in the commit message. > >> In a large multiple commit batch, many of the emails in the archive > >> were very out-of-order: > > > > Yeah, I'm hating that. I don't have much of an idea for fixing though > > other than adding a 'sleep 1' between the mails, making the commit take > > 17 seconds longer and hoping that fixes. > > Heh, that was going to be my suggestion as well. :) > > I doubt the timing matters too much on the receiving end -- people > usually don't obsessively reload their mail clients for commit mails, > I assume. Depending on the volume I might be worried about falling > too far behind, but that's probably not going to be too big of a > problem unless somebody pushes out hundreds of commits at a time. AFAIK, the git push command won't return until the post-receive hook returns, which is more of my concern with adding sleeps (especially if we need a 5 or 10 second sleep rather than a 1 second sleep.) Forking off a process to actually send the mails is definitely possible; we could even run the entire mail script in the background, but I'd generally prefer that bugs that cause it to fall over cause a backtrace on the pusher's terminal rather than silent misbehavior or something being logged some place that will never be read. (Weirdly, in thinking about forking off a subprocess, my first question is how to separate the mails in the stdin to the subprocess - add the envelope sender "From ... " lines that caused the problem with mhonarc??? ;-) - Owen _______________________________________________ gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
