git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Andreas Ericsson <exon@op5.com>
To: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Cc: Jeff King <peff@peff.net>, Michael Witten <mfwitten@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH RFC 1/6] Re: send-email: Add --delay for separating emails
Date: Wed, 08 Apr 2009 00:17:54 +0200	[thread overview]
Message-ID: <49DBD112.5000705@op5.se> (raw)
In-Reply-To: <20090407220854.GA12908@vidovic>

Nicolas Sebrecht wrote:
> On Tue, Apr 07, 2009 at 05:51:43PM -0400, Jeff King 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@gmail.com>
> 
>> 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.
> 
> IMHO, this improvement is broken by design. We try to fix a
> receiver-only issue by a sender side fix.
> 
> 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.
> 

The biggest problem with in-reply-to chains is that they're absolutely
horrible for patch-series of more than five or so messages. The "worst"
one this week was a series of 14 patches, I believe. If any of the
deeper nested patches gets any sort of commentary, it usually eats so
much horizontal screen estate that it becomes hopeless to actually
find anything.

Besides that, most mua's I've worked with list emails in a thread
like this:

 First
  +------ second
  |         +------ third
  |         |
  |         +---- reply to second
  |                 +
  |                 |
  |                 + reply to reply to second
  |
  +-- reply to first

etc. etc, but when asked for "next unread message in thread", they
jump to the *deepest* message in the thread first, so you end up
reading the replies to the patches in the wrong order anyway.

For those two reasons, I absolutely loathe deeply nested
in-reply-to chains.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

  reply	other threads:[~2009-04-07 22:19 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-07 21:25 [PATCH RFC 1/6] send-email: Add --delay for separating emails Michael Witten
2009-04-07 21:25 ` [PATCH RFC 2/6] send-email: --smtp-server-port should take an integer Michael Witten
2009-04-07 21:25   ` [PATCH RFC 3/6] send-email: Handle "GIT:" rather than "GIT: " during --compose Michael Witten
2009-04-07 21:25     ` [PATCH RFC 4/6] send-email: --compose takes optional argument to existing file Michael Witten
2009-04-07 21:25       ` [PATCH RFC 5/6] send-email: Cleanup the usage text a bit Michael Witten
2009-04-07 21:25         ` [PATCH RFC 6/6] send-email: Remove horrible mix of tabs and spaces Michael Witten
2009-04-07 21:35           ` demerphq
2009-04-07 21:42             ` Michael Witten
2009-04-07 21:44               ` demerphq
2009-04-07 21:57                 ` demerphq
2009-04-07 22:00               ` Jeff King
2009-04-07 22:10                 ` Andreas Ericsson
2009-04-07 23:33                   ` Tomas Carnecky
2009-04-08  2:02                   ` Jeff King
2009-04-11 19:22         ` [PATCH RFC 5/6] send-email: Cleanup the usage text a bit Junio C Hamano
2009-04-11 19:22       ` [PATCH RFC 4/6] send-email: --compose takes optional argument to existing file Junio C Hamano
2009-04-11 19:22     ` [PATCH RFC 3/6] send-email: Handle "GIT:" rather than "GIT: " during --compose Junio C Hamano
2009-04-11 20:45       ` Michael Witten
2009-04-12  0:59         ` Junio C Hamano
2009-04-12  2:36           ` Michael Witten
2009-04-07 23:20   ` [PATCH RFC 2/6] send-email: --smtp-server-port should take an integer Junio C Hamano
2009-04-11 19:22   ` Junio C Hamano
2009-04-11 21:01     ` Wesley J. Landaker
2009-04-11 21:07       ` Michael Witten
2009-04-07 21:51 ` [PATCH RFC 1/6] send-email: Add --delay for separating emails Jeff King
2009-04-07 22:08   ` [PATCH RFC 1/6] " Nicolas Sebrecht
2009-04-07 22:17     ` Andreas Ericsson [this message]
2009-04-08  6:05       ` Jeff King
2009-04-08  6:03     ` Jeff King
2009-04-07 23:17 ` [PATCH RFC 1/6] " Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2009-04-08 14:25 Michael Witten
2009-04-09 16:17 ` [PATCH RFC 1/6] " Nicolas Sebrecht
2009-04-09 17:27   ` Michael Witten
2009-04-09 17:38     ` Michael Witten
2009-04-09 17:45     ` Nicolas Sebrecht
2009-04-09 18:43       ` Michael Witten

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49DBD112.5000705@op5.se \
    --to=exon@op5.com \
    --cc=git@vger.kernel.org \
    --cc=mfwitten@gmail.com \
    --cc=nicolas.s-dev@laposte.net \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).