Re: Replacing Link trailers

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

On Mon, Oct 13, 2025 at 08:25:01AM -0400, Mathieu Desnoyers wrote:
> On 2025-10-13 07:53, James Bottomley wrote:

> > There has been a lot of discussion on the tooling list about how the
> > loss of link trailers has updated both tooling and triaging issues.
> > Konstantin has proposed a tool to get around this, but while that's in
> > development, I propose a discussion about making Link (or some
> > alternative tag) into the pointer that would work for everyone.

> AFAIU. this use of Link trailer is used as a strategy to work around
> the lack of unique identifier in patch commit messages that identifies
> multiple revisions of a patch, for tracking by patch review tooling
> and facilitate digging through patch history.

I believe a good percentage of the people actively using the links are
people looking at test results (that's me, and a bunch of others that
I've talked to).  My main usage is that I've got a failing test that
has been bisected to a commit that smells plausible enough and I want to
mail some people to tell them about the problem, I'm using the link to
grab a mailbox that I can reply to to reach a sensible set of people
with reasonable context.  In this context I don't particularly care
about the history of the patch, nor whatever review happened.  It's a
patch to email mapping.

> Based on prior email discussions I've seen, I don't think Linus is
> convinced that tagging commits with a unique identifier brings value,
> whereas people actively developing and using tools based on a
> workflow that relies on patch revision tracking see a lot of value
> in this.

TBH I'm not clear how the links/message IDs would be useful in that
context other than the history links which don't tend to get committed
since where people post them they're in the inter-version changelog
which gets dropped outside of DRM.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]