Re: [GIT PULL] ARM: Third batch of arm-soc changes for 3.10

From: Russell King - ARM Linux
Date: Tue May 07 2013 - 13:33:20 EST


On Tue, May 07, 2013 at 10:02:22AM -0700, Linus Torvalds wrote:
> So you seem to have blasted this series out with that automated
> script, so they all got sent basically at the same timestamp, and they
> are in the wrong order in my mailbox because email isn't that ordered.

Interesting. What I received here from the mailing list from Arnd
was:

Date: Tue, 7 May 2013 18:02:09 +0200
Subject: [GIT PULL] ARM: Third batch of arm-soc changes for 3.10

Date: Tue, 7 May 2013 18:02:10 +0200
Subject: [GIT PULL] ARM: arm-soc platform updates for 3.10, part 2

Date: Tue, 7 May 2013 18:02:11 +0200
Subject: [GIT PULL] ARM: arm-soc platform updates for 3.10, part 3

Date: Tue, 7 May 2013 18:02:12 +0200
Subject: [GIT PULL] ARM: arm-soc device tree changes, part 2

Date: Tue, 7 May 2013 18:02:13 +0200
Subject: [GIT PULL] ARM: arm-soc: late cleanups

Date: Tue, 7 May 2013 18:02:14 +0200
Subject: [GIT PULL] ARM: arm-soc: late Exynos multiplatform changes

So they do each have a different timestamp, and do come out right if
sorted by date-sent. Maybe one second is not long enough for gmail to
sort by date-sent? Sure, allowing a longer delay reduces the
possibility of stuff being reordered by MTAs, but it will never totally
eliminate that reordering - it just makes it less likely.

FWIR, gmail orders messages by order-of-reception only, not by
date-anything, which makes using delays to try to anticipate the
order of reception quite fruitless. And I suspect gmail doesn't show
you seconds (let alone give you Date: header.)

So I don't think that asking people to play games with delays between
consecutive messages is going to work all that well.

The only sure way would be to have it clearly marked in the subject
line, maybe in a similar way to how we mark patches using a
[GIT PULL N/M] thing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/