On Tue, Apr 07, 2009 at 04:25:17PM -0500, Michael Witten wrote: > When sending a patch series, the emails often arrive at the final > destination out of order; though these emails should be chained > via the In-Reply-To headers, some mail-viewing systems display > by order of arrival instead. > > The --delay option provides a means for specifying that there > should be a certain number of seconds of delay between sending > emails, so that the arrival order can be controlled better. > > Signed-off-by: Michael Witten <mfwitten@xxxxxxxxx> I'm a little dubious how well this works in practice. Have you done any experiments? The reason I am dubious is that you are presumably delaying only a few seconds (since anything more would be quite annoying to the user). This may deal with a short race condition in your local mail server. But what is the real cause of out-of-order delivery? Is it the local mail server seeing two messages essentially "simultaneously" and then reordering them randomly? Or is it other random delays that happen _after_ that, like network congestion, DNS lookups, down or congested servers, time it takes to deliver the actual message body (e.g., if your mail server sends two simultaneously, but the first one is much larger and takes longer to complete), etc. Those delays can be much larger than a few seconds, and this won't help at all there. I think it may still be reasonable to implement a solution that only covers some of the cases, but I what I am asking is if we know what percentage of the cases that is. If we are preventing only 1% of out-of-order deliveries with this, I question whether it is worth the bother. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html