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. On Tue, Apr 7, 2009 at 16:51, Jeff King wrote: > I'm a little dubious how well this works in practice. Have you done > any experiments? I have indeed, and I got better results. Whether that was a fluke, I can't say for sure. > [Delivery delays] can be much larger than a few seconds, and this > won't help at all there. and On Tue, Apr 7, 2009 at 18:17, Junio C Hamano wrote: > I do not think giving N second interval at the sending end would > help much in the real world. Between your submitting MUA (that's > "git-send-email") and the client MUA, there are many hops involved... > any single hop can batch the messages that arrive within a small time > window before passing them to the next hop, and it can reorder the > messages when it does so. > > In short, the only thing your --delay can control is the arrival > interval at your outgoing MSA. The arrival interval and order of > messages are outside your control for later hops. For the most part, yes, I am operating under the assumption that email is sent as soon as it is received by any intervening hop (no batch accumulation). However, I'm also postulating that there always exists an N that serves as an upperbound on the transit time, regardless of batching. That's where these comment comes into play: On Tue, Apr 7, 2009 at 16:51, Jeff King wrote: > 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). On Wed, Apr 8, 2009 at 01:03: > A multi-second delay is downright annoying. As a sender, I don't think > I would enable this option. However, this sentiment doesn't make sense to me. Firstly, I presume that someone is electing to use this option, so it is almost by definition not annoying for that person. Secondly, it seems reasonable to drop into another VC, screen window, or terminal instance, and then set send-email a-running. For instance, with a 14-patch series, one could set `--delay 60' and then let send-email run happily for the next 14 minutes with nary a thought. However, I think you're coming at it from a different angle: On Wed, Apr 8, 2009 at 01:03, Jeff King wrote: > But apparently many readers sort by date received. See this subthread: > > http://article.gmane.org/gmane.comp.version-control.git/110097 > > I am generally of the opinion that if it is a big problem for people, > they should get a better mail client. But I am also open to suggestions > for helping receivers on crappy mail clients as long as those > suggestions do not put a burden on the sender. and on Tue, Apr 7, 2009 at 17:08, Nicolas Sebrecht wrote: > If the receiver wants the patch series be in a good ordered _for > sure_, he has to switch to a client mail supporting the In-Reply-To > chains. Frankly, I don't care how other people's patch series appear to me. I care about how mine appear to others. Is this irrational? Probably, but I'm kind of OC; I want my patch series to look like it's in order for everyone. This has nothing to do with what the receiver wants. This has everything to do with what the sender wants. I want my patch series to be in order even for wrongheaded receivers. So, I never had any intention of forcing a delay on the sending end. It is strictly for the sending end to use if desired. On Tue, Apr 7, 2009 at 18:17, Junio C Hamano wrote: > I think send-email already has hacks to timestamp the messages at > least one-second apart by shifting the Date: field, so that the > recipient MUA can sort by the departure timestamp if it wants to (and > if it can), instead of the arrival timestamp. Is it not working well > for you? I have worked with 2 major mail clients that both display by date received: * Mac OS X's Mail * Gmail I assume that a not-insignificant number of others also use these clients. I don't mind letting send-email run in the background for a few minutes if it means my patch series appear in order. As you say, Jeff: > On Wed, Apr 08, 2009 at 12:08:54AM +0200, Nicolas Sebrecht wrote: >> IMHO, this improvement is broken by design. We try to fix a >> receiver-only issue by a sender side fix. > > I almost said the same thing: it is really the receiver's problem. > However, that doesn't mean the sender can't do simple things to help > hint the right thing to the receiver. For example, we already munge the > date fields to make sure the timestamp in each patch is increasing. There's nothing simpler than slowing the rate of outgoing email. It doesn't even have to be used; it is completely unintrusive and fully automated. It even works with the confirmation. Best of all, it didn't take much code to implement. Sincerely, Michael Witten -- 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