lkml.org 
[lkml]   [2018]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 2/2] send-email: supply a --send-delay=1 by default
    Date

    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.

    \
     
     \ /
      Last update: 2018-03-26 00:01    [W:3.074 / U:0.784 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site