On Wed, Apr 08, 2009 at 12:08:54AM +0200, Nicolas Sebrecht wrote:
> > 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.
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.
So there is precedent for giving hints to help the receiver sort the
patches. But munging the date fields is relatively transparent to the
sener. A multi-second delay is downright annoying. As a sender, I don't
think I would enable this option.
> 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.
That's not enough for shallow-style patch series, like:
PATCH 0/3
\->PATCH 1/3
\->PATCH 2/3
\->PATCH 3/3
which is the proposed default for v1.6.3.
Many readers will sort by rfc822 date within a single thread level,
which is sufficient with what send-email currently generates. Sorting by
subject should also work fine.
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.
-Peff
--
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