Re: [PATCH RFC 1/6] send-email: Add --delay for separating emails

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 7, 2009, 23:17 UTC
Message-ID: <7vd4boxdd9.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1239139522-24118-1-git-send-email-mfwitten@gmail.com>

Michael Witten <mfwitten@gmail.com> writes:

Show 8 quoted lines

> 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.

If you are trying to force the order of messages that the client MUA physically receives the messages, 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:

 * Your outgoing MSA (typically your ISP's sendmail) your MUA hands
   messages to;

 * Your ISP's internal mail routing chain of MTAs that forward the
   messages around;

 * The recipient's ISP's incoming MTA that receives the messages from
   your ISP's outgoing MTA;

 * The recipient's ISP's internal mail routing chain of MTAs that
   forward the messages around, until they reach...

 * ... the mailbox at recipient's ISP that stores the messages until the
   recipient picks them up;

 * And finally the recipient's MUA that reads from the mailbox.

Messages your MUA sends out can take different paths in the above chain even though the final destination (mailbox at the recipient's ISP) may be the same, and different mailpaths can and do have different latencies. Even if all the messages sent out by a single invocation of your submitting MUA happened to take the same mailpath, 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.

On the other hand, 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?