Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Sun, Mar 25 2018, brian m. carlson wrote:

> On Sun, Mar 25, 2018 at 06:28:03PM +0000, Ævar Arnfjörð Bjarmason wrote:
>> The earlier change to add this option described the problem this
>> option is trying to solve.
>>
>> This turns it on by default with a value of 1 second, which'll
>> hopefully solve it, and if not user reports as well as the
>> X-Mailer-Send-Delay header should help debug it.
>>
>> I think the trade-off of slowing down E-Mail sending to turn this on
>> makes sense because:
>>
>>  * GMail is a really common client, git.git's own unique authors by
>>    %aE are ~30% @gmail.com, ~20% for linux.git. That's just patch
>>    submitters, my guess is this it's much more common among those who
>>    mostly read the list, and those users who aren't using mu4e / mutt
>>    etc. anyway.
>>
>>  * There's really no point in having this feature at all if it's not
>>    made the default, since the entire point is to be able to read a
>>    list like the git ML or the LKML and have patches from others show
>>    up in order.
>>
>>  * I don't think anyone's really sensitive to the sending part of
>>    send-email taking longer. You just choose "all" and then switch to
>>    another terminal while it does its thing if you have a huge series,
>>    and for 1-3 patches I doubt anyone would notice this anyway.
>
> I'm not sure that this is going to have the effect you want it to have.
> Let me give an example to demonstrate why.
>
> If I send a series to the list, in order for this to work, you need my
> SMTP server (Postfix) to essentially send mails slowly enough to
> vger.kernel.org (ZMailer) that it doesn't batch them when it sends them
> to GMail.  The problem is that with my mail server, due to filtering and
> such, already takes at least a second to accept, process, and relay
> submitted messages.  vger still batched them and delivered them back to
> me out of order.  This will be even worse with large series.
>
> You are also assuming that my mail server will not have batched them and
> delivered them out of order, which it might well do, since Postfix uses
> a connection cache to machines that don't do STARTTLS (which, much to my
> annoyance, vger doesn't offer).
>
> In short, I don't think this is going to be especially helpful because
> it won't change the status quo for a lot of senders.  You'd have to
> insert some significant delay in order to get the effect you desire, and
> even then things could still be delivered out of order.

Good point. I also see that (via git log --author=Ævar --grep='^\[PATCH
') that this series itself arrived out of order (0 -> 2 -> 1), but I
don't know to what extent public-inbox itself might be batching things.

It would be interesting to get reports from other GMail users as to what
order these mails were shown in, but I think as soon as they're replied
to that info's gone, at least for 2/2, which is the potentially out of
order one in this case.

In general I realize that this won't be a general solution that'll work
in all cases. E.g. I have a local SMTP on my laptop, if I'm on a plane
it wouldn't matter if the delay was 2 hours, it would be batched up
locally and sent all at once.

I was hoping we could find some sweet spot where the systems along the
way (common smtpd's, majordomo, public-inbox's git repo) would as a
result get this right most of the time for the purposes of appeasing
this really common mail client, but maybe that's not going to work out.