I have two different threads for patchset Ia5f01679c928a9053cfd05d26fe1a03b67dac433, even though the subject is exactly the same and they are only few days apart.
I could understand this, if the subject changed, even though even then I would like to have all emails related to one patchset in one thread.
Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49250
Looking at the Gerrit emails I have, it looks like Gerrit is letting mchenry create Message-ID headers. Or mchenry is overwriting Gerrit's code.
It looks like Gerrit is including proper In-Reply-To or References headers in the emails, so fixing Message-IDs to match would fix the problem.
So, there is probably some configuration error since Gerrit bug reports show that it does know about Message-Id.
Also see: https://code.google.com/p/gerrit/issues/detail?id=237
https://code.google.com/p/gerrit/issues/detail?id=1246
Yeah I looked at this already. I'm pretty sure it's bug 237 or 1246 (or a combination of both).
Links to the issues mentioned in comment 2: http://code.google.com/p/gerrit/issues/detail?id=237 and http://code.google.com/p/gerrit/issues/detail?id=1246
Now that we have upgraded to Gerrit 2.12 I have revisited the upstream bugs and replied there. Below is a summary of my conclusion:
https://bugs.chromium.org/p/gerrit/issues/detail?id=237
Is from 2010, the replies lack a Reply-To header which is used for threading on most mail clients. Some clients still rely solely on the subject but that is hopeless to fix.
I have found emails from our Gerrit 2.8 and they had Reply-To.
https://bugs.chromium.org/p/gerrit/issues/detail?id=1246
The message ID is forged based on a Unix timestamp with millisecond precision and the bug report is about the replies using an id that has second precision (the last three digits of the timestamp are always 0).
Might be due to the database backend or some java cruft.
On our setup:
Gerrit 2.8.x
Initial email:
Message-ID: <gerrit.1464706059637.Iac5b1be23dd9b657f43bd7d5a3fe5ddff326e25f@gerrit.wikimedia.org>
The replies have:
In-Reply-To: <gerrit.1464706059000.Iac5b1be23dd9b657f43bd7d5a3fe5ddff326e25f@gerrit.wikimedia.org>
threading is broken. Same as upstream issue 1246.
Gerrit 2.12.2
Initial message:
Message-ID: <gerrit.1469566572000.I00747c84db95c8862a36170e6e6f668a24e80bbb@gerrit.wikimedia.org>
Replies:
In-Reply-To: <gerrit.1469566572000.I00747c84db95c8862a36170e6e6f668a24e80bbb@gerrit.wikimedia.org>
The timestamp lacks the miliseconds precision. It is namespaced with the change id so there is not going to be a thread having mails from different changes.
The root cause was the unique id being inconsistent due to timestamp precision. For an unknown reason it is now using second precision for both initial email and the replies and the threading should be fixed on all mail client supporting In-Reply-To. Thunderbird is such example.
Lacking some timestamp precision could kind of suck in theory. But since that ID is based on a single change and should be based on the first message I don't think that matters all that much. Consistency trumps all here.
So I think this will all mostly work depending on how intelligent your client is in respecting Message-IDs and In-Reply-Tos
BUT! This is ignoring when the subject line changes 😉
From ChangeSubject.vm:
## Optionally $change.originalSubject can be used for the first subject ## in a change. This allows subject based email clients such as GMail ## to thread comments together even if subsequent patch sets change the ## first line of the commit message.
But I'm not a fan. If a subject line of a change shifts, I think the e-mail subject line should change along with it--changes can move in a different direction and the old subject line could be anything from inaccurate to completely opposite of what's being done.
Some clients will still thread this properly. It sounds like GMail and others...just won't... New subject line: new thread for them.
So with all this being said, I'm going to close it resolved. It should work for most well-behaved clients, but it seems like some clients just won't behave here. For them it's declined.