Replacing Link trailers

Replacing Link trailers

[James Bottomley]

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.

Regards,

James

Re: Replacing Link trailers

[Mathieu Desnoyers]

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 think it's important to spell out the problem this is trying to
solve from the get go.

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.

Putting this in context may help listing the possible solutions that
go beyond links and evaluate the best solution. For instance, gerrit
uses change id tags such as:

Change-Id: I9bfbee7a3219c3f293cee2bafce7233ec34d3e84

to track the various revisions of a patch. Unlike "Link" tags, it is
clear that it's only meant to be a unique identifier for the various
revisions of a patch, and it's not meant to be used as a link.

AFAIU the use of "Link" tags for that purpose tried to achieve a
similar goal, but ends up polluting the information seen by humans,
which is an unwanted side-effect.

It's great to hear that Konstantin is working on this. I look forward
to see what comes out of it.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Re: Replacing Link trailers

[James Bottomley]

On Mon, 2025-10-13 at 08:25 -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.

Actually no.  Link merely linked the commit back to the original email.
There was a proposal, by Thomas Gleixner also to have back links in
cover letters, which some people do, that would allow recovery of the
whole email history, but absent that it goes back only to the last
iteration.  However, the last iteration is sufficient for the tools.

> I think it's important to spell out the problem this is trying to
> solve from the get go.
> 
> 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.
> 
> Putting this in context may help listing the possible solutions that
> go beyond links and evaluate the best solution. For instance, gerrit
> uses change id tags such as:
> 
> Change-Id: I9bfbee7a3219c3f293cee2bafce7233ec34d3e84

Rally, no.  The point is not to track the patch across multiple changes
in git, but to track the email discussions.  Gerrit is git based so
there are multiple commits in the gerrit/github/git workflow where the
same patch appears with a different commit id.  In Linux we don't
really do this except in rebaseable trees we don't care about (and the
odd same patch different trees scenario) so it's definitely about
tracking emails not commits.

> to track the various revisions of a patch. Unlike "Link" tags, it is
> clear that it's only meant to be a unique identifier for the various
> revisions of a patch, and it's not meant to be used as a link.
> 
> AFAIU the use of "Link" tags for that purpose tried to achieve a
> similar goal, but ends up polluting the information seen by humans,
> which is an unwanted side-effect.
> 
> It's great to hear that Konstantin is working on this. I look forward
> to see what comes out of it.

That's b4 dig ... it's based on fuzzy matching of the patch-id
currently, I believe.

Regards,

James

Re: Replacing Link trailers

[Mark Brown]

[-- 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 --]

Re: Replacing Link trailers

[Guenter Roeck]

On 10/13/25 05:25, 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 think it's important to spell out the problem this is trying to
> solve from the get go.
> 
> 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.
> 
> Putting this in context may help listing the possible solutions that
> go beyond links and evaluate the best solution. For instance, gerrit
> uses change id tags such as:
> 
> Change-Id: I9bfbee7a3219c3f293cee2bafce7233ec34d3e84
> 
> to track the various revisions of a patch. Unlike "Link" tags, it is
> clear that it's only meant to be a unique identifier for the various
> revisions of a patch, and it's not meant to be used as a link.
> 

It also does not (necessarily) track patch revisions, and I would find
it confusing if it did. Gerrit supports tracking patch revisions. That
mechanism that would be defeated if a new revision would get a new
Change-Id.

Guenter

Re: Replacing Link trailers

[Steven Rostedt]

On Mon, 13 Oct 2025 08:25:01 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> 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.

That's not how I use it at all. Copying my reply from the tooling thread
here:

  [..]

So it allows you to not only find the cover letter of a series, but also
daisy chains all the links to previous versions so you can see how the
patch was developed, and all the comments to the older versions.

Now my workflow incorporates these link tags. When I need to create a new
version of the patch, I save the old git branch with its version:

  git branch topic-v1
  git reset --hard <base-commit>

Then I download the old version from patchwork, run my scripts to pull it
in (which adds the links to the emails of those commits). And when I make the
next version, I record the changes by replacing the:

  Link: https://lore.kernel.org/...

With

  Changes since v1: https://lore.kernel.org/...

And before sending my emails, I move that text below the '---'.

And this makes it very easy to incorporate the daisy chain. If I have to
use any external tooling to search for it, I'm not going to bother, and
this workflow will just stop happening.

-- Steve

Re: Replacing Link trailers

[Johannes Berg]

On Mon, 2025-10-13 at 08:25 -0400, Mathieu Desnoyers wrote:
> 
> Based on prior email discussions I've seen, I don't think Linus is
> convinced that tagging commits with a unique identifier brings value,

Well ... the way I read it, he's basically saying "it's useless to me so
you don't get to do it."

> whereas people actively developing and using tools based on a
> workflow that relies on patch revision tracking see a lot of value
> in this.

It's not just that, btw. We use it much for tracking the internal vs.
external version of a commit, which may differ due to kernel version
backports (e.g. added ifdefs or changes to additional files that aren't
upstream [yet]) that don't and sometimes shouldn't exist upstream.

All of this discussion pretends that whatever happens to a commit
outside the context of upstream is entirely irrelevant, but I suspect
that for many of us not purely tasked with 'develop upstream', but
rather 'enable device X' or similar don't have the luxury of ignoring
everything that happened before something went upstream.

There are already _so_ many roadblocks for contributing upstream. This
just adds another one. On the one hand, it's just another "small" one. I
don't believe it's as small as some people would like to believe, "b4
dig" will do nothing for "life before upstream" type usages.

Ultimately, this is yet another question of how much you want to make
life harder for contributors of all sorts. A link gives bug reporters
who somehow find a commit (e.g. bisect) more context to go on [1], gives
people working on things like hardware enabling that happens pre-
upstream (in a way) a lot of context, makes things faster in general,
etc.

And we're taking it away because literally *one* person thinks that it
adds irrelevant noise.

[1] Sure, they can use 'b4 dig' if you pretend they all already know to
use it.

</rant>

But seriously, why is this such a big thing? Linus is, in general,
asking literally everyone else much much more to suit his ways in the
kernel than "don't click the link if it starts with patch.msgid.link"
...

johannes

Re: Replacing Link trailers

[Steven Rostedt]

On Tue, 14 Oct 2025 21:12:33 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:

> And we're taking it away because literally *one* person thinks that it
> adds irrelevant noise.

Are you suggesting that we lost the "benevolent" in our "benevolent dictator"?

  ;-)

-- Steve

Re: Replacing Link trailers

[Johannes Berg]

On Tue, 2025-10-14 at 15:35 -0400, Steven Rostedt wrote:
> On Tue, 14 Oct 2025 21:12:33 +0200
> Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> > And we're taking it away because literally *one* person thinks that it
> > adds irrelevant noise.
> 
> Are you suggesting that we lost the "benevolent" in our "benevolent dictator"?
> 
>   ;-)

So I'm supposed to be on vacation this week, but this is haunting me I
guess ... I see your ";-)", but I'll respond anyway.

Yes. Yes, in this particular instance I am absolutely saying that.

To me, there's a sort of underlying (social) contract in all of Linux
etc. - yes, we want/need Linus to enforce the things that make for
unpopular reading in the press (say kicking out bcachefs for a recent
example), but we also trust him to "read the room" (so to speak) and
mostly at least, form an opinion informed by the rough consensus. At
least that's my interpretation of how this all works. Call me deluded if
you like. (Seriously, tell me, even in private messages.)

Here, however, we have the exact opposite. Pretty much everyone in the
threads disagrees and prefers a tag in some form (be it link, message-
id, or something else), and yet Linus insists he's right to be annoyed
and impose his will on everyone. Some people in the threads want to find
technological workarounds for his whims, but really all those are just
that: workarounds, and demonstrably don't work as well.

It's not even a technical problem/discussion, if it were, we'd be
reading messages that take the concerns of those people who currently
rely on the link tags seriously, and try to find solutions that work for
everyone. I'm sure we could think of any number of things, even encoding
the message-id in the git commit object format (so it's invisible with
default git log/show format) itself would probably work pretty easily.
But no, instead we read all about how those people are all wrong and
misguided, and how the patch that got applied isn't special [1]. In
other contexts, we'd probably call this "mansplaining", but here we
somehow are supposed to not only tolerate but celebrate, presumably for
the great technological advancement it brings. [2]

[1] seriously? even if it were posted 100 times identically, the one
that got applied would be made special by the very act of being picked
up by the maintainer

[2] b4 dig is (probably) nice, and Linus will likely somehow manage to
have it interpreted that it was because of his actions that it came
about, although it really wasn't his vision but rather his pettiness
that got it started.


So really, I think this has become purely an ego/power dynamics thing,
far detached from any practical reality. _Not_ clicking a link really
isn't that difficult, and distinguishing between "I've modified a patch
so it needs a link now" and "a lookup by patch-id will succeed so no
link is needed" has now become fig-leaf for the naked emperor. It adds
useless work for everyone, not to mention wasting server cycles to do a
search and all that, all because one guy desperately needed to be right.

(But yes, I'm sure that now that everyone is so entrenched, big ego will
win.)

So yeah, circling back to "benevolent" -- for me, this has definitely
broken the "benevolent" part and a lot of trust. But that's fine, I can
also do a job that heavily resolves around following a manager's
arbitrary whims. But my heart won't be in it.

johannes

Re: Replacing Link trailers

[Steven Rostedt]

On Thu, 16 Oct 2025 00:01:38 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:

> So yeah, circling back to "benevolent" -- for me, this has definitely
> broken the "benevolent" part and a lot of trust. But that's fine, I can
> also do a job that heavily resolves around following a manager's
> arbitrary whims. But my heart won't be in it.

Yes it does appear that we all have extra work to do because one person
doesn't like the current method. I don't think I saw anyone else complain
about the "useless" link either. Maybe I missed it. But currently it's all
been "Alright, fine, I'll work around this" and not one "Oh Great! This is
most definitely helpful!", like what happened when Linus created "git".

I'm currently looking for someone to help me with my maintainership. Masami
came on board, but what happened was that he basically maintains all things
"probe" related and I do everything else. That split still takes up more
time than we have designated.

Unfortunately, I've had many people say to me "I don't ever want to be a
top level maintainer" and "better you than me", which makes it very
difficult to find a helper. This discussion isn't helping with that
perspective either.

-- Steve

Re: Replacing Link trailers

[Simona Vetter]

On Thu, 16 Oct 2025 at 00:22, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, 16 Oct 2025 00:01:38 +0200
> Johannes Berg <johannes@sipsolutions.net> wrote:
>
> > So yeah, circling back to "benevolent" -- for me, this has definitely
> > broken the "benevolent" part and a lot of trust. But that's fine, I can
> > also do a job that heavily resolves around following a manager's
> > arbitrary whims. But my heart won't be in it.
>
> Yes it does appear that we all have extra work to do because one person
> doesn't like the current method. I don't think I saw anyone else complain
> about the "useless" link either. Maybe I missed it. But currently it's all
> been "Alright, fine, I'll work around this" and not one "Oh Great! This is
> most definitely helpful!", like what happened when Linus created "git".
>
> I'm currently looking for someone to help me with my maintainership. Masami
> came on board, but what happened was that he basically maintains all things
> "probe" related and I do everything else. That split still takes up more
> time than we have designated.
>
> Unfortunately, I've had many people say to me "I don't ever want to be a
> top level maintainer" and "better you than me", which makes it very
> difficult to find a helper. This discussion isn't helping with that
> perspective either.

+1 on both Steve's observation and Johannes' entire mail.
-Sima
-- 
Simona Vetter
Software Engineer
http://blog.ffwll.ch

Re: Replacing Link trailers

[Hans de Goede]

Hi,

On 16-Oct-25 12:16 PM, Simona Vetter wrote:
> On Thu, 16 Oct 2025 at 00:22, Steven Rostedt <rostedt@goodmis.org> wrote:
>> On Thu, 16 Oct 2025 00:01:38 +0200
>> Johannes Berg <johannes@sipsolutions.net> wrote:
>>
>>> So yeah, circling back to "benevolent" -- for me, this has definitely
>>> broken the "benevolent" part and a lot of trust. But that's fine, I can
>>> also do a job that heavily resolves around following a manager's
>>> arbitrary whims. But my heart won't be in it.
>>
>> Yes it does appear that we all have extra work to do because one person
>> doesn't like the current method. I don't think I saw anyone else complain
>> about the "useless" link either. Maybe I missed it. But currently it's all
>> been "Alright, fine, I'll work around this" and not one "Oh Great! This is
>> most definitely helpful!", like what happened when Linus created "git".
>>
>> I'm currently looking for someone to help me with my maintainership. Masami
>> came on board, but what happened was that he basically maintains all things
>> "probe" related and I do everything else. That split still takes up more
>> time than we have designated.
>>
>> Unfortunately, I've had many people say to me "I don't ever want to be a
>> top level maintainer" and "better you than me", which makes it very
>> difficult to find a helper. This discussion isn't helping with that
>> perspective either.
> 
> +1 on both Steve's observation and Johannes' entire mail.

+1 from me on both too.

Or as Geert put it: "So, can we please get our Link:-tags back, and get back
to real work (or vacation ;-)?"

Regards,

Hans

Re: Replacing Link trailers

[David Woodhouse]

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

On Wed, 2025-10-15 at 18:22 -0400, Steven Rostedt wrote:
> On Thu, 16 Oct 2025 00:01:38 +0200
> Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> > So yeah, circling back to "benevolent" -- for me, this has definitely
> > broken the "benevolent" part and a lot of trust. But that's fine, I can
> > also do a job that heavily resolves around following a manager's
> > arbitrary whims. But my heart won't be in it.
> 
> Yes it does appear that we all have extra work to do because one person
> doesn't like the current method. I don't think I saw anyone else complain
> about the "useless" link either.

I agree. I think we're spending a lot of time trying to reinvent
something that *was* working already.

Even when a Link: header points to a lore.kernel.org link which is a
plain one-off posting of the patch without any discussion, I *still*
find those useful at times, because I can *see* that there was no such
discussion.

And if I've now found that patch to be the cause of a regression, I
will reply to that message to *start* the discussion.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: Replacing Link trailers

[Geert Uytterhoeven]

Hi Linus,

On Thu, 16 Oct 2025 at 00:01, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2025-10-14 at 15:35 -0400, Steven Rostedt wrote:
> > On Tue, 14 Oct 2025 21:12:33 +0200
> > Johannes Berg <johannes@sipsolutions.net> wrote:
> > > And we're taking it away because literally *one* person thinks that it
> > > adds irrelevant noise.
> >
> > Are you suggesting that we lost the "benevolent" in our "benevolent dictator"?
> >
> >   ;-)
>
> So I'm supposed to be on vacation this week, but this is haunting me I
> guess ... I see your ";-)", but I'll respond anyway.

[...]

So, can we please get our Link:-tags back, and get back to real work
(or vacation ;-)?

Thanks a lot!

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Replacing Link trailers

[Doug Anderson]

Hi,

On Tue, Oct 14, 2025 at 12:13 PM Johannes Berg
<johannes@sipsolutions.net> wrote:
>
> And we're taking it away because literally *one* person thinks that it
> adds irrelevant noise.
>
> [1] Sure, they can use 'b4 dig' if you pretend they all already know to
> use it.
>
> </rant>
>
> But seriously, why is this such a big thing? Linus is, in general,
> asking literally everyone else much much more to suit his ways in the
> kernel than "don't click the link if it starts with patch.msgid.link"

Right. I think this is why it bothers me so much. There are so many
people that are so passionate about wanting to keep the existing
"Link:" tag usage. ...and these are senior people who have been
contributing for years. "b4 dig" is nice and I'm happy it's being
created, but it still seems like it's not as good at some workflows
and adds needless imprecision/heuristics/AI when a "Link:" tag would
be precise.

It seems weird to discount all the senior people who find the existing
use of the "Link:" tag valuable when those that don't find it valuable
could just ignore it. "Doctor, it pains me when I click on the Link
tag, what should I do?" Answer: don't click on the "Link:" tag.

-Doug

Re: Replacing Link trailers

[Dan Carpenter]

I cloned the latest b4 to get dig.

Why does everything go to stderr instead of stdout?  There is a lot of
debug output so I think it's still in the demo stage?  Personally, I only
want the last version of the patch which was merged so I have to pipe it
to `grep https: | head -n 1`.

I did a test to see how well it works and it works 88% of the time.  Here
are the results from 100 digs where you can see version number bumps
aren't sent to the list, parisc and some ceph changes don't through lore?

regards,
dan carpenter

3a8660878839 ("Linux 6.18-rc1")
a8482d2c9071 https://lore.kernel.org/r/20251011103153.2354-1-wsa+renesas@sang-engineering.com
54b91e54b113 https://lore.kernel.org/r/20251011112032.77be18e4@gandalf.local.home
fd6db5886792 https://lore.kernel.org/r/20251011-null-barn-fix-v1-1-5fe5af5b8fd8@suse.cz
bda745ee8fbb https://lore.kernel.org/r/20251011194257.174203652@kernel.org
b0f2942a1601 https://lore.kernel.org/r/20251010-kbuild-fix-mod-device-syms-reloc-err-v1-1-6dc88143af25@kernel.org
ce740955b238 https://lore.kernel.org/r/20251009183630.5451-2-wsa+renesas@sang-engineering.com
f7045387a681 https://lore.kernel.org/r/20251009111500.75198-2-wsa+renesas@sang-engineering.com
9338d660b79a https://lore.kernel.org/r/20251008-kbuild-fix-modinfo-regressions-v1-3-9fc776c5887c@kernel.org
8ec3af916fe3 https://lore.kernel.org/r/20251008-kbuild-fix-modinfo-regressions-v1-2-9fc776c5887c@kernel.org
4b47a3aefb29 https://lore.kernel.org/r/20251008-kbuild-fix-modinfo-regressions-v1-1-9fc776c5887c@kernel.org
accb9a7e87f0 https://lore.kernel.org/r/20251008102628.808045-3-kafai.wan@linux.dev
4f375ade6aa9 https://lore.kernel.org/r/20251007012235.755853-2-kafai.wan@linux.dev
07ca98f906a4 https://lore.kernel.org/r/20251008165659.4141318-1-aleksander.lobakin@intel.com
b30c32c784bf ("cifs: update internal version number")
dc6b72497401 https://lore.kernel.org/r/20251010131058.69778-1-robh@kernel.org
b5f8aa8d4bde https://lore.kernel.org/r/20250924-gpio-shared-v1-1-775e7efeb1a3@linaro.org
a29ad21b9886 https://lore.kernel.org/r/20250829175152.9704-2-daleksan@redhat.com
207696b17f38 https://lore.kernel.org/r/20250918193019.4018706-1-jarkko@kernel.org
8a81236f2cb0 https://lore.kernel.org/r/20250915182105.6664-1-gunnarku@amazon.com
64a7cfbcf548 https://lore.kernel.org/r/20250731215255.113897-3-ebiggers@kernel.org
2c2615c84238 https://lore.kernel.org/r/20250731215255.113897-2-ebiggers@kernel.org
4bddf4587c13 https://lore.kernel.org/r/20250825203223.629515-1-jarkko@kernel.org
fa9fe8715055 https://lore.kernel.org/r/20250831123602.14037-17-pali@kernel.org
92210ccd877b https://lore.kernel.org/r/20250107002311.28954-1-pali@kernel.org
88cae132dc05 https://lore.kernel.org/r/20250107002311.28954-1-pali@kernel.org
057ac50638bc https://lore.kernel.org/r/20250608170119.6813-5-pali@kernel.org
15df28699b28 https://lore.kernel.org/r/f91c6079ef9764c7e23abd80ceab39a35f39417f.1759964186.git.fthain@linux-m68k.org
f4edb5c52c93 ("parisc: Fix iodc and device path return values on old machines")
44ac7f5c6d4c ("parisc: Firmware: Fix returned path for PDC_MODULE_FIND on older machines")
9db26d5855d0 https://lore.kernel.org/r/20241203-rtc-uie-irq-fixes-v1-6-01286ecd9f3f@geanix.com
1502fe0e97be https://lore.kernel.org/r/20241203-rtc-uie-irq-fixes-v1-5-01286ecd9f3f@geanix.com
e0762fd26ad6 https://lore.kernel.org/r/20241203-rtc-uie-irq-fixes-v1-3-01286ecd9f3f@geanix.com
9ffe06b6ccd7 https://lore.kernel.org/r/20241203-rtc-uie-irq-fixes-v1-2-01286ecd9f3f@geanix.com
795cda8338ea https://lore.kernel.org/r/20241203-rtc-uie-irq-fixes-v1-1-01286ecd9f3f@geanix.com
7ae6152b7831 https://lore.kernel.org/r/20250929132805.220558-2-ematsumiya@suse.de
be3898a395f8 ("smb: client: remove redudant assignment in cifs_strict_fsync()")
dba9f997c9d9 https://lore.kernel.org/r/20251007192326.234467-4-pc@manguebit.org
b95cd1bdf5aa https://lore.kernel.org/r/20251006190854.103483-3-pc@manguebit.org
57ce9f7793b7 https://lore.kernel.org/r/20251006164220.67333-2-pc@manguebit.org
110fee6b9bb5 https://lore.kernel.org/r/20251006190854.103483-1-pc@manguebit.org
0cc380d0e1d3 https://lore.kernel.org/r/20251005064952.4056-1-wangfushuai@baidu.com
68d2e2ca1cba https://lore.kernel.org/r/20251004021143.230223-1-henrique.carvalho@suse.com
1643cd51ba97 https://lore.kernel.org/r/7a5c4b6d-f15e-4071-8a82-dca6b71b6b4b@web.de
eb4faf634388 https://lore.kernel.org/r/20251004154808.116143-2-dev@kael-k.io
434689e97195 https://lore.kernel.org/r/20251001212416.4871-1-hansg@kernel.org
fea8cdf6738a https://lore.kernel.org/r/20251008-airoha-loopback-mode-fix-v2-1-045694fe7f60@kernel.org
5d683e550540 https://lore.kernel.org/r/20251003233025.1157158-10-kuba@kernel.org
fbb467f0ed95 https://lore.kernel.org/r/20251007232653.2099376-9-kuba@kernel.org
0be740fb22da https://lore.kernel.org/r/20251003233025.1157158-8-kuba@kernel.org
2eecd3a41e67 https://lore.kernel.org/r/20251003233025.1157158-7-kuba@kernel.org
27ba92560bcc https://lore.kernel.org/r/20251003233025.1157158-6-kuba@kernel.org
1ad3f62089af https://lore.kernel.org/r/20251003233025.1157158-5-kuba@kernel.org
858b78b24af2 https://lore.kernel.org/r/20251003233025.1157158-4-kuba@kernel.org
613e9e8dcb7e https://lore.kernel.org/r/20251007232653.2099376-3-kuba@kernel.org
7e617d57f2a2 https://lore.kernel.org/r/20251003233025.1157158-2-kuba@kernel.org
6bb73db6948c ("crypto: essiv - Check ssize for decryption and in-place encryption")
64cf7d058a00 https://lore.kernel.org/r/2025101305-harsh-moisture-93ae@gregkh
de4cbd704731 https://lore.kernel.org/r/20251008172516.20697-1-ankitkhushwaha.linux@gmail.com
d74d6c0e9895 ("ceph: add bug tracking system info to MAINTAINERS")
a154f141604a https://lore.kernel.org/r/tencent_8C54420E1B0FF8D804C1B4651DF970716309@qq.com
22c73d52a6d0 https://lore.kernel.org/r/20250729170240.118794-1-khiremat@redhat.com
c66120c84295 https://lore.kernel.org/r/20250902190844.125833-2-slava@dubeyko.com
98a2850de49c https://lore.kernel.org/r/20250828184441.83336-2-slava@dubeyko.com
6140f1d43ba9 ("libceph: add empty check to ceph_con_get_out_msg()")
7399212dcf64 ("libceph: pass the message pointer instead of loading con->out_msg")
59699a5a7114 https://lore.kernel.org/r/20250806094855.268799-2-max.kellermann@ionos.com
fbeafe782bd9 ("ceph: fix potential race condition on operations with CEPH_I_ODIRECT flag")
53db6f25ee47 https://lore.kernel.org/r/20250708192057.539725-1-slava@dubeyko.com
5824ccba9a39 ("ceph: fix potential race condition in ceph_ioctl_lazyio()")
5b2d1377d6cc https://lore.kernel.org/r/20250606190545.438240-1-slava@dubeyko.com
1ed4471a4ee6 https://lore.kernel.org/r/20250606190521.438216-1-slava@dubeyko.com
b7ed1e29cfe7 https://lore.kernel.org/r/20250606190432.438187-1-slava@dubeyko.com
fa073039466f ("ceph: make ceph_start_io_*() killable")
27c0a7b05d13 https://lore.kernel.org/r/20250731190227.16187-1-ebiggers@kernel.org
c834a97962c7 https://lore.kernel.org/r/20251013144429.966496922@linuxfoundation.org
4f7bf54b07e5 https://lore.kernel.org/r/20251009152420.751067844@kernel.org
f0c029d2ff42 https://lore.kernel.org/r/20251001130907.364673-2-thorsten.blum@linux.dev
e9a9dcb4ccb3 https://lore.kernel.org/r/1b3a55134d4a9a39acab74b8566bf99864393efc.1759914262.git.asml.silence@gmail.com
09cfd3c52ea7 https://lore.kernel.org/r/b0441e746c0a840908ec3e3881f782b5e84aa6d3.1759914280.git.asml.silence@gmail.com
455281c0ef4e https://lore.kernel.org/r/20251007181205.228473-1-pedrodemargomes@gmail.com
deabb34b66b9 https://lore.kernel.org/r/20251002155423.466142-1-thuth@redhat.com
e84945bdc619 https://lore.kernel.org/r/20251008125942.25056-5-fw@strlen.de
a126ab6b26f1 https://lore.kernel.org/r/20251008125942.25056-4-fw@strlen.de
bbf0c98b3ad9 https://lore.kernel.org/r/20251008125942.25056-3-fw@strlen.de
f359b809d54c https://lore.kernel.org/r/20251008100816.8526-1-fmancera@suse.de
229c586b5e86 ("crypto: skcipher - Fix reqsize handling")
c7866ee0a9dd https://lore.kernel.org/r/20251005023335.166483-1-marek.vasut@mailbox.org
2c95a756e0cf https://lore.kernel.org/r/20251006204029.7169-2-thomas@wismer.xyz
e475fa420e6c https://lore.kernel.org/r/20251006115640.497169-1-arnd@kernel.org
f52ce0ea90c8 https://lore.kernel.org/r/20250926162034.1785899-1-yang@os.amperecomputing.com
28bba2c2935e https://lore.kernel.org/r/20251003155238.2147410-1-ryan.roberts@arm.com
f04aad36a07c https://lore.kernel.org/r/20250930063921.62354-1-acsjakub@amazon.de
b93af2cc8e03 https://lore.kernel.org/r/20250930004410.55228-1-sj@kernel.org
9658d698a8a8 https://lore.kernel.org/r/20250930081040.80926-1-lance.yang@linux.dev
1ce6473d17e7 https://lore.kernel.org/r/20250922021458.68123-1-lance.yang@linux.dev
fcc0669c5aa6 https://lore.kernel.org/r/20250922220203.261714-1-shakeel.butt@linux.dev
90eb9ae35727 https://lore.kernel.org/r/20250917174033.3810435-5-rppt@kernel.org
a667300bd53f https://lore.kernel.org/r/20250903063018.3346652-2-rppt@kernel.org
8375b76517cb https://lore.kernel.org/r/20250917174033.3810435-3-rppt@kernel.org

Re: Replacing Link trailers

[Doug Anderson]

Hi,

On Mon, Oct 13, 2025 at 4:53 AM James Bottomley
<James.Bottomley@hansenpartnership.com> 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.

A few random ideas to throw out there:

1. Could we submit a change to the "git" tool to allow something like
the "Link" tag but hide it from the default settings? I'm thinking
something like how "git" only shows the Author/AuthorDate by default
until you say "--format=fuller" and then it also shows you the
Commit/CommitDate. Then we just tell Linus to keep the setting off and
everyone is happy.

2. Given how "everyone" thinks AI is the best thing ever, could AI
help the patch trackers find the version history of the patch / links
to old versions? So when you click on a Link it takes you someplace
where AI has already found links to all the old patches and perhaps
even summarized the mailing list discussion? Maybe this is a terrible
idea and we'd all get flamed the moment the AI gives some bad info,
but somehow it seemed wrong to not suggest an AI solution in this day
and age. :-P

3. Could folks somehow just stage an intervention and tell Linus that
he's wrong and just has to accept the Link tag that he finds useless?
;-)  (Hi Linus! I'm sure you're not reading this, right?) While I
certainly can't consider my opinion to hold much weight, it sure seems
like quite a few prominent people in the community find the Link tag
very useful and are sad to see it go. Given all the people that find
the tag useful, it kinda feels like it could stay? Even if Linus has a
10:1 or 100:1 vote in the topic, from what I gather keeping the "Link"
tag would still win (assuming people that don't give a crap just
abstain instead of voting "no"). Not that this is a democracy or
anything...


-Doug

Re: Replacing Link trailers

[James Bottomley]

On Mon, 2025-10-13 at 08:40 -0700, Doug Anderson wrote:
> Hi,
> 
> On Mon, Oct 13, 2025 at 4:53 AM James Bottomley
> <James.Bottomley@hansenpartnership.com> 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.
> 
> A few random ideas to throw out there:
> 
> 1. Could we submit a change to the "git" tool to allow something like
> the "Link" tag but hide it from the default settings? I'm thinking
> something like how "git" only shows the Author/AuthorDate by default
> until you say "--format=fuller" and then it also shows you the
> Commit/CommitDate. Then we just tell Linus to keep the setting off
> and everyone is happy.

Just on this, git format actually controls the amount of information it
prints from the headers rather than the trailers (the git tools are
really designed to treat the trailers simply as body text).  However,
that's not to say Link couldn't become a header tag instead of a
trailer.

Regards,

James

Re: Replacing Link trailers

[Steven Rostedt]

On Mon, 13 Oct 2025 12:31:32 -0400
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> Just on this, git format actually controls the amount of information it
> prints from the headers rather than the trailers (the git tools are
> really designed to treat the trailers simply as body text).  However,
> that's not to say Link couldn't become a header tag instead of a
> trailer.

I just need it to be visible from patchwork.

-- Steve

Re: Replacing Link trailers

[Theodore Ts'o]

On Mon, Oct 13, 2025 at 01:39:13PM -0400, Steven Rostedt wrote:
> On Mon, 13 Oct 2025 12:31:32 -0400
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > Just on this, git format actually controls the amount of information it
> > prints from the headers rather than the trailers (the git tools are
> > really designed to treat the trailers simply as body text).  However,
> > that's not to say Link couldn't become a header tag instead of a
> > trailer.
> 
> I just need it to be visible from patchwork.

Instead of the Link: tag, would this suffice for you?

    Message-ID: <20251007134936.7291-2-jack@suse.cz>

In some ways, it's easier since raw the message Id is directly
available in Patchwork.

						- Ted

Re: Replacing Link trailers

[H. Peter Anvin]

On October 13, 2025 10:50:31 AM PDT, Theodore Ts'o <tytso@mit.edu> wrote:
>On Mon, Oct 13, 2025 at 01:39:13PM -0400, Steven Rostedt wrote:
>> On Mon, 13 Oct 2025 12:31:32 -0400
>> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>> 
>> > Just on this, git format actually controls the amount of information it
>> > prints from the headers rather than the trailers (the git tools are
>> > really designed to treat the trailers simply as body text).  However,
>> > that's not to say Link couldn't become a header tag instead of a
>> > trailer.
>> 
>> I just need it to be visible from patchwork.
>
>Instead of the Link: tag, would this suffice for you?
>
>    Message-ID: <20251007134936.7291-2-jack@suse.cz>
>
>In some ways, it's easier since raw the message Id is directly
>available in Patchwork.
>
>						- Ted
>

Oh my.

Irony.

This was the *original* definition that I proposed, which was vetoed by Linus because it didn't provide a clickable experience. The compromise was to have an URL schema that:

a) fully encodes the message ID, so that the death of any specific archive doesn't mean irreversible information loss;

b) is encoded under the kernel.org domain name, so it is under our direct control. 

In IETF terms, we want an identifier that is both a URL and a URN (senso lato.)

Re: Replacing Link trailers

[Linus Torvalds]

On Mon, 13 Oct 2025 at 12:07, H. Peter Anvin <hpa@zytor.com> wrote:
>
> This was the *original* definition that I proposed, which was vetoed by Linus because it didn't provide a clickable experience.

Yeah., I still don't believe that Message-ID is any better than a link.

And the only believable argument *for* this all is the "one-click experience".

Because I still believe that "if you use tools, then 'b4 dig' is
better than *any* pointless tag that just is entirely redundant and
only cuts down on the available information".

So the one-click argument actually resonates with me, even if that is
very obviously not the workflow I use. At least I *understand* that
argument.

All the other arguments seem just disingenuous in that they literally
give less useful information than "b4 dig" does.

"more noise for less information" is not a good argument in my book.

           Linus

Re: Replacing Link trailers

[James Bottomley]

On Mon, 2025-10-13 at 12:20 -0700, Linus Torvalds wrote:
> On Mon, 13 Oct 2025 at 12:07, H. Peter Anvin <hpa@zytor.com> wrote:
> > 
> > This was the *original* definition that I proposed, which was
> > vetoed by Linus because it didn't provide a clickable experience.
> 
> Yeah., I still don't believe that Message-ID is any better than a
> link.
> 
> And the only believable argument *for* this all is the "one-click
> experience".
> 
> Because I still believe that "if you use tools, then 'b4 dig' is
> better than *any* pointless tag that just is entirely redundant and
> only cuts down on the available information".

I think we could possibly get the best of both worlds.  Once b4 dig
works well enough, it should be possible to do that server side as well
as client side, so we could get lore to do the server side stuff and
have a lore link that produces the output taking a message-id as input
like the link: tags do now (say https://lore.kernel.org/dig/<msgid>)

That way the tooling that uses msgid would still work (with a bit of
tweaking) and there is a clickable link that hopefully provides more
useful information.

Regards,

James

Re: Replacing Link trailers

[H. Peter Anvin]

On 2025-10-13 12:35, James Bottomley wrote:
>>
>> Because I still believe that "if you use tools, then 'b4 dig' is
>> better than *any* pointless tag that just is entirely redundant and
>> only cuts down on the available information".
> 
> I think we could possibly get the best of both worlds.  Once b4 dig
> works well enough, it should be possible to do that server side as well
> as client side, so we could get lore to do the server side stuff and
> have a lore link that produces the output taking a message-id as input
> like the link: tags do now (say https://lore.kernel.org/dig/<msgid>)
> 
> That way the tooling that uses msgid would still work (with a bit of
> tweaking) and there is a clickable link that hopefully provides more
> useful information.
> 

See my other reply. This might work *strictly* in a Linux kernel context, but
the goal should be git-universal tooling, and the Message-ID simply does not
contain enough information.

	-hpa

Re: Replacing Link trailers

[H. Peter Anvin]

On 2025-10-13 12:20, Linus Torvalds wrote:
> On Mon, 13 Oct 2025 at 12:07, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> This was the *original* definition that I proposed, which was vetoed by Linus because it didn't provide a clickable experience.
> 
> Yeah., I still don't believe that Message-ID is any better than a link.
> 
> And the only believable argument *for* this all is the "one-click experience".
> 
> Because I still believe that "if you use tools, then 'b4 dig' is
> better than *any* pointless tag that just is entirely redundant and
> only cuts down on the available information".
> 
> So the one-click argument actually resonates with me, even if that is
> very obviously not the workflow I use. At least I *understand* that
> argument.
> 
> All the other arguments seem just disingenuous in that they literally
> give less useful information than "b4 dig" does.
> 
> "more noise for less information" is not a good argument in my book.
> 

And I very much agree with you -- see my other reply.

	-hpa

Re: Replacing Link trailers

[Doug Anderson]

Hi,

On Mon, Oct 13, 2025 at 12:20 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, 13 Oct 2025 at 12:07, H. Peter Anvin <hpa@zytor.com> wrote:
> >
> > This was the *original* definition that I proposed, which was vetoed by Linus because it didn't provide a clickable experience.
>
> Yeah., I still don't believe that Message-ID is any better than a link.
>
> And the only believable argument *for* this all is the "one-click experience".
>
> Because I still believe that "if you use tools, then 'b4 dig' is
> better than *any* pointless tag that just is entirely redundant and
> only cuts down on the available information".
>
> So the one-click argument actually resonates with me, even if that is
> very obviously not the workflow I use. At least I *understand* that
> argument.
>
> All the other arguments seem just disingenuous in that they literally
> give less useful information than "b4 dig" does.

Wow, I hadn't heard of "b4 dig" and it doesn't appear to have landed
yet. ...but I searched and it was easy to find a reference. I'll check
it out. Oh, it's using AI. I guess my suggestion that we should use AI
to solve this problem was more on point than I realized. ;-) ;-) ;-)

OK, I found Sasha's RFC [1].

The first thing I note is that "b4 dig" takes a Message-Id as an
argument. So now I'm confused. I must be misunderstanding the problem
we're trying to solve with the "Link:" tag?!

From how I've used it, the "Link" tag allows you to start with a
commit hash in Linux and then go from there to a mailing list post
(and/or Message-Id). ...and then it was suggested that we don't need a
"Link" tag (or anything containing "Message-Id") because "b4 dig"
solves the problem. ...but then "b4 dig" needs a Message-Id to work?
Eh?

[1] https://lore.kernel.org/all/20250909163214.3241191-1-sashal@kernel.org/

-Doug

Re: Replacing Link trailers

[H. Peter Anvin]

On 2025-10-13 13:34, Doug Anderson wrote:
> 
> OK, I found Sasha's RFC [1].
> 
> The first thing I note is that "b4 dig" takes a Message-Id as an
> argument. So now I'm confused. I must be misunderstanding the problem
> we're trying to solve with the "Link:" tag?!
> 
> From how I've used it, the "Link" tag allows you to start with a
> commit hash in Linux and then go from there to a mailing list post
> (and/or Message-Id). ...and then it was suggested that we don't need a
> "Link" tag (or anything containing "Message-Id") because "b4 dig"
> solves the problem. ...but then "b4 dig" needs a Message-Id to work?
> Eh?
> 

So "b4 dig" needs to be able to decode the Link encoding schema (which is
pretty trivial: the final path element of the URL should be a URL-escaped
message-ID.)

	-hpa

Re: Replacing Link trailers

[Laurent Pinchart]

On Mon, Oct 13, 2025 at 01:34:05PM -0700, Doug Anderson wrote:
> On Mon, Oct 13, 2025 at 12:20 PM Linus Torvalds wrote:
> > On Mon, 13 Oct 2025 at 12:07, H. Peter Anvin wrote:
> > >
> > > This was the *original* definition that I proposed, which was vetoed by Linus because it didn't provide a clickable experience.
> >
> > Yeah., I still don't believe that Message-ID is any better than a link.
> >
> > And the only believable argument *for* this all is the "one-click experience".
> >
> > Because I still believe that "if you use tools, then 'b4 dig' is
> > better than *any* pointless tag that just is entirely redundant and
> > only cuts down on the available information".
> >
> > So the one-click argument actually resonates with me, even if that is
> > very obviously not the workflow I use. At least I *understand* that
> > argument.
> >
> > All the other arguments seem just disingenuous in that they literally
> > give less useful information than "b4 dig" does.
> 
> Wow, I hadn't heard of "b4 dig" and it doesn't appear to have landed
> yet. ...but I searched and it was easy to find a reference. I'll check
> it out. Oh, it's using AI. I guess my suggestion that we should use AI
> to solve this problem was more on point than I realized. ;-) ;-) ;-)
> 
> OK, I found Sasha's RFC [1].

I think the one discussed in this mail thread is the implementation from
Konstantin, available from
https://git.kernel.org/pub/scm/utils/b4/b4.git/.

> The first thing I note is that "b4 dig" takes a Message-Id as an
> argument. So now I'm confused. I must be misunderstanding the problem
> we're trying to solve with the "Link:" tag?!
> 
> From how I've used it, the "Link" tag allows you to start with a
> commit hash in Linux and then go from there to a mailing list post
> (and/or Message-Id). ...and then it was suggested that we don't need a
> "Link" tag (or anything containing "Message-Id") because "b4 dig"
> solves the problem. ...but then "b4 dig" needs a Message-Id to work?
> Eh?
> 
> [1] https://lore.kernel.org/all/20250909163214.3241191-1-sashal@kernel.org/

-- 
Regards,

Laurent Pinchart

Re: Replacing Link trailers

[Vlastimil Babka]

On 10/13/25 22:34, Doug Anderson wrote:
> Hi,
> 
> On Mon, Oct 13, 2025 at 12:20 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> On Mon, 13 Oct 2025 at 12:07, H. Peter Anvin <hpa@zytor.com> wrote:
>> >
>> > This was the *original* definition that I proposed, which was vetoed by Linus because it didn't provide a clickable experience.
>>
>> Yeah., I still don't believe that Message-ID is any better than a link.
>>
>> And the only believable argument *for* this all is the "one-click experience".
>>
>> Because I still believe that "if you use tools, then 'b4 dig' is
>> better than *any* pointless tag that just is entirely redundant and
>> only cuts down on the available information".
>>
>> So the one-click argument actually resonates with me, even if that is
>> very obviously not the workflow I use. At least I *understand* that
>> argument.
>>
>> All the other arguments seem just disingenuous in that they literally
>> give less useful information than "b4 dig" does.
> 
> Wow, I hadn't heard of "b4 dig" and it doesn't appear to have landed
> yet. ...but I searched and it was easy to find a reference. I'll check
> it out. Oh, it's using AI. I guess my suggestion that we should use AI
> to solve this problem was more on point than I realized. ;-) ;-) ;-)
> 
> OK, I found Sasha's RFC [1].

You found the wrong one. See this one:

https://lore.kernel.org/all/20251010-muscular-camel-of-acumen-00eeaf@lemur/

But if your point was to demonstrate how searching for a subject can lead to
the wrong outcome, good job :)

> The first thing I note is that "b4 dig" takes a Message-Id as an
> argument. So now I'm confused. I must be misunderstanding the problem
> we're trying to solve with the "Link:" tag?!
> 
> From how I've used it, the "Link" tag allows you to start with a
> commit hash in Linux and then go from there to a mailing list post
> (and/or Message-Id). ...and then it was suggested that we don't need a
> "Link" tag (or anything containing "Message-Id") because "b4 dig"
> solves the problem. ...but then "b4 dig" needs a Message-Id to work?
> Eh?
> 
> [1] https://lore.kernel.org/all/20250909163214.3241191-1-sashal@kernel.org/
> 
> -Doug
> 

Re: Replacing Link trailers

[Doug Anderson]

Hi,

On Mon, Oct 13, 2025 at 1:59 PM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> >> All the other arguments seem just disingenuous in that they literally
> >> give less useful information than "b4 dig" does.
> >
> > Wow, I hadn't heard of "b4 dig" and it doesn't appear to have landed
> > yet. ...but I searched and it was easy to find a reference. I'll check
> > it out. Oh, it's using AI. I guess my suggestion that we should use AI
> > to solve this problem was more on point than I realized. ;-) ;-) ;-)
> >
> > OK, I found Sasha's RFC [1].
>
> You found the wrong one. See this one:
>
> https://lore.kernel.org/all/20251010-muscular-camel-of-acumen-00eeaf@lemur/
>
> But if your point was to demonstrate how searching for a subject can lead to
> the wrong outcome, good job :)

Crap, that's funny. Yeah, all the top Google searches for "b4 dig" are
all for Sasha's tool. Konstantin's patch, while landed, isn't in the
most recent "versioned" b4 release (v0.14.3), so I didn't see it.
...and yes, it does somewhat prove the point that just trying to match
on "subject" can be dangerous. I've run into the issue where lore
pages don't seem to be consistently findable in Google in the past and
I guess it struck again...

OK, so Konstantin's version at least solves my problem of getting a
mailing list post from a commit hash, which is good. It uses "git
patch-id" which is a really great/exact solution when it works. It
won't always work, of course. Sometimes maintainers/committers find
merge conflicts when we try to apply and, if folks are feeling
generous and it's easy, folks won't request a re-send. That messes up
patch-id.

Luckily "b4 dig" falls back to subject matching. As per above, that's
not always perfect but probably works more than 95% of the time?

So I guess given the correct pointer to "b4 dig", it seems like a
pretty workable solution for me. It will fail/be wrong sometimes, but
probably less often than I had to deal with a maintainer that didn't
put "Link:" tags in the past. I could still wish that maintainers
could still put "Link:" tags to really document where they obtained
the patch from, but oh well, one can't have everything.

-Doug

Re: Replacing Link trailers

[Sasha Levin]

On Mon, Oct 13, 2025 at 02:46:31PM -0700, Doug Anderson wrote:
>Hi,
>
>On Mon, Oct 13, 2025 at 1:59 PM Vlastimil Babka <vbabka@suse.cz> wrote:
>>
>> >> All the other arguments seem just disingenuous in that they literally
>> >> give less useful information than "b4 dig" does.
>> >
>> > Wow, I hadn't heard of "b4 dig" and it doesn't appear to have landed
>> > yet. ...but I searched and it was easy to find a reference. I'll check
>> > it out. Oh, it's using AI. I guess my suggestion that we should use AI
>> > to solve this problem was more on point than I realized. ;-) ;-) ;-)
>> >
>> > OK, I found Sasha's RFC [1].
>>
>> You found the wrong one. See this one:
>>
>> https://lore.kernel.org/all/20251010-muscular-camel-of-acumen-00eeaf@lemur/
>>
>> But if your point was to demonstrate how searching for a subject can lead to
>> the wrong outcome, good job :)
>
>Crap, that's funny. Yeah, all the top Google searches for "b4 dig" are
>all for Sasha's tool. Konstantin's patch, while landed, isn't in the
>most recent "versioned" b4 release (v0.14.3), so I didn't see it.
>...and yes, it does somewhat prove the point that just trying to match
>on "subject" can be dangerous. I've run into the issue where lore
>pages don't seem to be consistently findable in Google in the past and
>I guess it struck again...

Right - I tried solving a slightly different problem: I don't necessarily care
about the original posting, but I care a lot about any discussions around a
commit (whether they're in the same thread as the submission or a completely
different thread that happen prior to the submission).

So while we can use fuzzy logic like the one "b4 dig" uses, "b4 ai dig" tries
to take it one step further and mine the mailing list for more related
information.

-- 
Thanks,
Sasha

Re: Replacing Link trailers

[Mark Brown]

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

On Mon, Oct 13, 2025 at 01:34:05PM -0700, Doug Anderson wrote:
> On Mon, Oct 13, 2025 at 12:20 PM Linus Torvalds

> > All the other arguments seem just disingenuous in that they literally
> > give less useful information than "b4 dig" does.

> Wow, I hadn't heard of "b4 dig" and it doesn't appear to have landed
> yet. ...but I searched and it was easy to find a reference. I'll check
> it out. Oh, it's using AI. I guess my suggestion that we should use AI
> to solve this problem was more on point than I realized. ;-) ;-) ;-)

> OK, I found Sasha's RFC [1].

Konstantin has an initial implementation in b4 tip which is not
currently using AI but rather falling through a stack of heuristics to
try to figure something out.  It's a commitish to lore link lookup tool.

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

Re: Replacing Link trailers

[H. Peter Anvin]

On 2025-10-13 12:07, H. Peter Anvin wrote:
> 
> Oh my.
> 
> Irony.
> 
> This was the *original* definition that I proposed, which was vetoed by Linus because it didn't provide a clickable experience. The compromise was to have an URL schema that:
> 
> a) fully encodes the message ID, so that the death of any specific archive doesn't mean irreversible information loss;
> 
> b) is encoded under the kernel.org domain name, so it is under our direct control. 
> 
> In IETF terms, we want an identifier that is both a URL and a URN (senso lato.)
>

Another way to look at it is whether to put the bulk of the burden on the
sender or receiver. There are arguments both ways, however, I think Linus does
have a point for a couple of reasons:

1. Move burden away from the maintainer/reviewer.
2. The number of tools used for *reading* usually vastly outnumber the tool
   used for *writing*.
3. A resource name provides no hint whatsoever as to how to locate and
   retrieve said resource. git is used for many projects, and so it isn't
   reasonable to automatically assume any one mailing list or other
   collection, such as LKML. Thus, the Message-ID: alone is insufficient.

There are a few downsides:

a. It implies a default user experience; visiting an alternative archive or a
   local archive requires decoding the link back to its original.
b. Mis-encoding at the source or not using an approved schema violates the
   constraint that the resource name is recoverable, and it may not be
   immediately obvious (early on we saw a lot of Link:s to lkml.org, which
   did not encode the message-ID in any meaningful form.)
c. It makes it at least somewhat harder to deal with links to embargoed
   discussions which will become public, as it is unlikely the embargoed
   discussion will be archived as the same URL as when it becomes public.

Personally, for me, item 3 is the one that really clinches it. Since
Message-ID alone is insufficient, I don't believe it is possible to trust the
user to encode all the appropriate information in a way that is generic across
projects (the original proposal was for an ad hoc LKML tag containing the
Message-ID). The Link: tag provides at least that much of a general solution
to this problem, and it can also link to genuine web resources for the kinds
of projects where this kind of information is not processed via email.

As far as the downsides, all of them can all be handled with tooling in the
form of an URL pattern rewriter. This is very easy when a link is invoked by
executing a browser; when it is internal to the browser and/or invoked via
some kind of IPC API then it gets more difficult, needing a browser-specific
plugin or using a proxy.

As far as Patchwork is concerned, that should be a rather obvious feature
(encode Message-ID as a Link tag) to add to Patchwork. There are several other
features Patchwork really needs, one of the main ones being a way to supercede
an individual patch in a series.

	-hpa

Re: Replacing Link trailers

[dan.j.williams]

Doug Anderson wrote:
> Hi,
> 
> On Mon, Oct 13, 2025 at 4:53 AM James Bottomley
> <James.Bottomley@hansenpartnership.com> 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.
> 
> A few random ideas to throw out there:
> 
> 1. Could we submit a change to the "git" tool to allow something like
> the "Link" tag but hide it from the default settings? I'm thinking
> something like how "git" only shows the Author/AuthorDate by default
> until you say "--format=fuller" and then it also shows you the
> Commit/CommitDate. Then we just tell Linus to keep the setting off and
> everyone is happy.

A place to stash metadata that: stays out of mainline, is readily
available to the subsystem maintainer and anyone interacting with the
submaintainer's tree, git notes.

Towards this end I drafted a b4 feature:

http://lore.kernel.org/20251014071530.3665691-1-dan.j.williams@intel.com

Note I still think 'b4 dig; is needed for other use cases, but a git
note in my local tree restores my workflow.

Re: Replacing Link trailers

[Greg KH]

On Tue, Oct 14, 2025 at 09:01:32AM -0700, dan.j.williams@intel.com wrote:
> Doug Anderson wrote:
> > Hi,
> > 
> > On Mon, Oct 13, 2025 at 4:53 AM James Bottomley
> > <James.Bottomley@hansenpartnership.com> 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.
> > 
> > A few random ideas to throw out there:
> > 
> > 1. Could we submit a change to the "git" tool to allow something like
> > the "Link" tag but hide it from the default settings? I'm thinking
> > something like how "git" only shows the Author/AuthorDate by default
> > until you say "--format=fuller" and then it also shows you the
> > Commit/CommitDate. Then we just tell Linus to keep the setting off and
> > everyone is happy.
> 
> A place to stash metadata that: stays out of mainline, is readily
> available to the subsystem maintainer and anyone interacting with the
> submaintainer's tree, git notes.

The "problem" with git notes is that for those of us working with the
"whole tree" at times, we would then have to go and dig across all
subsystems to try to find where the notes are.  So unless we have one
big "all the notes merged into one" tree somewhere, it's going to be
very unwieldy for many of us (i.e. all the distros/stable/release
people doing triage and bug reports.)

thanks,

greg k-h

Re: Replacing Link trailers

[dan.j.williams]

Greg KH wrote:
> On Tue, Oct 14, 2025 at 09:01:32AM -0700, dan.j.williams@intel.com wrote:
> > Doug Anderson wrote:
> > > Hi,
> > > 
> > > On Mon, Oct 13, 2025 at 4:53 AM James Bottomley
> > > <James.Bottomley@hansenpartnership.com> 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.
> > > 
> > > A few random ideas to throw out there:
> > > 
> > > 1. Could we submit a change to the "git" tool to allow something like
> > > the "Link" tag but hide it from the default settings? I'm thinking
> > > something like how "git" only shows the Author/AuthorDate by default
> > > until you say "--format=fuller" and then it also shows you the
> > > Commit/CommitDate. Then we just tell Linus to keep the setting off and
> > > everyone is happy.
> > 
> > A place to stash metadata that: stays out of mainline, is readily
> > available to the subsystem maintainer and anyone interacting with the
> > submaintainer's tree, git notes.
> 
> The "problem" with git notes is that for those of us working with the
> "whole tree" at times, we would then have to go and dig across all
> subsystems to try to find where the notes are.  So unless we have one
> big "all the notes merged into one" tree somewhere, it's going to be
> very unwieldy for many of us (i.e. all the distros/stable/release
> people doing triage and bug reports.)

Agree. I still expect 'b4 dig' is needed for that case, and I think
per-subsystem notes can help it along. I.e. part of what it can do is
walk a Link: in a pull / merge request to find the source git tree and
then see if that tree has notes. Otherwise, it can fallback to
attempting patch-id matching, or vice-versa, attempt patch-id first and
fallback to trying to find notes.

Re: Replacing Link trailers

[dan.j.williams]

Greg KH wrote:
> So unless we have one big "all the notes merged into one" tree
> somewhere

...circling back to say. Why *not* do this?

When Linus says:

> And maybe lore could even have particular indexing for the data you
> are interested in if that helps.
> 
> In my experience, Konstantin has been very responsive when people have
> asked for those kinds of things (both b4 and lore).

...why not a notes tree? Make a convention for subsystems to annotate
notes updates in pull requests. Linus workflow does not change,
mainline metadata unaffected, but pr-tracker-bot is enabled to update
the central 'notes' tree. This gives a path for subsystems to ship
metadata that their downstreams care about.

Re: Replacing Link trailers

[James Bottomley]

On Wed, 2025-10-15 at 10:09 -0700, dan.j.williams@intel.com wrote:
> Greg KH wrote:
> > So unless we have one big "all the notes merged into one" tree
> > somewhere
> 
> ...circling back to say. Why *not* do this?
> 
> When Linus says:
> 
> > And maybe lore could even have particular indexing for the data you
> > are interested in if that helps.
> > 
> > In my experience, Konstantin has been very responsive when people
> > have
> > asked for those kinds of things (both b4 and lore).
> 
> ...why not a notes tree? Make a convention for subsystems to annotate
> notes updates in pull requests. Linus workflow does not change,
> mainline metadata unaffected, but pr-tracker-bot is enabled to update
> the central 'notes' tree.

I think part of the problem with notes is they're designed not to be
shared.  So there are lots of diverse internal uses for notes that
aren't just the annotations you're thinking of here, so when I push to
a notes tree, I'd likely have to filter and when I pull from it I
wouldn't necessarily want everyone else's notes ... it's like when you
forget to add --no-tags to a pull from someone else's tree and you get
a load of their internal tags that contaminates your internal tag pool.

>  This gives a path for subsystems to ship metadata that their
> downstreams care about.

Yes, but not all subsystems would care about everything even in this
notes driven annotations model ... so you either have to have filter on
pull or strict rules about what goes in, which then causes issues with
local notes uses.

That's not to say we can't make it work, but I think if something is
important enough to be global it should be part of the commit tree in
some form.

Regards,

James

RE: Replacing Link trailers

[Luck, Tony]

> Yes, but not all subsystems would care about everything even in this
> notes driven annotations model ... so you either have to have filter on
> pull or strict rules about what goes in, which then causes issues with
> local notes uses.
>
> That's not to say we can't make it work, but I think if something is
> important enough to be global it should be part of the commit tree in
> some form.

Konstantin could run a bot every time Linus pushes a tree to "b4 dig"
all the new non merge commits to build a public map of commit->e-mail.

Doing this would also provide a potentially useful audit to find any commits
that don't have any obvious e-mail discussion.

-Tony

Re: Replacing Link trailers

[Konstantin Ryabitsev]

On Wed, Oct 15, 2025 at 10:09:33AM -0700, dan.j.williams@intel.com wrote:
> > So unless we have one big "all the notes merged into one" tree
> > somewhere
> 
> ...circling back to say. Why *not* do this?

Git notes are fragile, they have important scalability problems (they are all
just files in a single ref, so if you have a million annotated commits, you
have a million files split across a bunch of two-letter prefixed dirs), and
when multiple writers are editing notes, you will have conflicts and merges.

It's not a great medium for a system that's supposed to be continuously added
to.

I have pondered this multiple times and my preferred approach would be to have
a machine-readable feed that can be indexed and searched. To me, it makes
sense to make it a public-inbox feed that is just RFC-2822 messages, but
that's obviously because I have a large public-inbox hammer. Our transparency
feed operates this way:

https://git.kernel.org/pub/scm/infra/transparency-logs/gitolite/git/1.git/plain/m

We could have the same approach with commit annotations.

E.g. if a patch is merged by a submaintainer:

    From: somebot: <...>
    Subject: commit annotation for abcd...7890
    X-For-Commit-ID: abcd...7890
    X-For-Patch-ID: bcde....8901
    References: <some@message-id>
    [other headers like Date, Message-ID, etc]

    ---
    source: pub/scm/linux/kernel/git/subsystem/linux
    link: https://patch.msgid.link/some@message-id
    type: merge
    description |
                Merged by somemaintainer@kernel.org

If it is then merged into mainline:
    
    From: somebot: <...>
    Subject: commit annotation for abcd...7890
    X-For-Commit-ID: abcd...7890
    X-For-Patch-ID: bcde....8901
    References: <some@message-id>
    [other headers like Date, Message-ID, etc]

    ---
    source: pub/scm/linux/kernel/git/subsystem/linux
    link: https://patch.msgid.link/some@message-id
    type: merge
    description |
                Merged by torvalds@linuxfoundation.org

If it is then mentioned in a bug report:

    From: SomeOtherBot <...>
    Subject: commit annotation for abcd...7890
    X-For-Commit-ID: abcd...7890
    [other headers like Date, Message-ID, etc]

    ---
    source: https://bugzilla.kernel.org/bug/12345
    link: https://bugzilla.kernel.org/bug/12345/comment1
    type: bug
    description: |
                 Mentioned in bug 12345 comment 1 as possible source of
                 data corruption in frobfs under high loads.

This is trivial to search for if we're indexing X-For-Commit-ID headers and
then trivial to parse to get a full "medical history" of a commit. Anyone can
clone this and run their own analysis on it using heuristic or AI tools.

This generally goes into my vision of lore as a "message bus" of sorts for
everything to do with Linux development. It's unwieldy for a human, but we're
gradually entering into an era where automated agents are able to efficiently
analyze the firehose and tame it for maintainers. Maybe.

-K

Re: Replacing Link trailers

[dan.j.williams]

Konstantin Ryabitsev wrote:
> On Wed, Oct 15, 2025 at 10:09:33AM -0700, dan.j.williams@intel.com wrote:
> > > So unless we have one big "all the notes merged into one" tree
> > > somewhere
> > 
> > ...circling back to say. Why *not* do this?
> 
> Git notes are fragile, they have important scalability problems (they are all
> just files in a single ref, so if you have a million annotated commits, you
> have a million files split across a bunch of two-letter prefixed dirs), and
> when multiple writers are editing notes, you will have conflicts and merges.
> 
> It's not a great medium for a system that's supposed to be continuously added
> to.

Ack.

> I have pondered this multiple times and my preferred approach would be to have
> a machine-readable feed that can be indexed and searched. To me, it makes
> sense to make it a public-inbox feed that is just RFC-2822 messages, but
> that's obviously because I have a large public-inbox hammer. Our transparency
> feed operates this way:
> 
> https://git.kernel.org/pub/scm/infra/transparency-logs/gitolite/git/1.git/plain/m
> 
> We could have the same approach with commit annotations.

I like it.

[..]
> This is trivial to search for if we're indexing X-For-Commit-ID headers and
> then trivial to parse to get a full "medical history" of a commit. Anyone can
> clone this and run their own analysis on it using heuristic or AI tools.
> 
> This generally goes into my vision of lore as a "message bus" of sorts for
> everything to do with Linux development. It's unwieldy for a human, but we're
> gradually entering into an era where automated agents are able to efficiently
> analyze the firehose and tame it for maintainers. Maybe.

Yeah, and this addresses the other problem with git notes is that they
do not follow commits as they get backported. I.e. I think folks were
using the submission Link: trailer as a persistent cookie.

The main motivations for git notes for me were to restore the ergonomic
experience of reading a commit in gitweb/cgit in the browser and just
clicking over to lore to read the thread, and to help track commit state
relative to mailing list postings over revisions. That can stay local to
a subsystem repo and like you suggest, let a feed handle all the other
forensics folks need.

Re: Replacing Link trailers

[Linus Torvalds]

On Wed, 15 Oct 2025 at 11:37, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>>
> Git notes are fragile, they have important scalability problems (

Yeah, I don't think git notes are the answer - they are good for
purely *local* notes, but they just don't distribute well.

I think people would be a *lot* better off with b4 integration in
their workflow.

For example, I don't know how many people use git hooks. I personally
only do a couple: mainly I use them to do signature verification so
that I don't miss the "oh, somebody sent me pull request without a
signed tag".

I didn't always notice the lack of successful tag verification.

So I have a commit hook that makes it very obvious when I don't have a
key or when the tag was an unsigned one.

How about the people who love their link tags look at making them
*conscious*. That's what I hate about the current situation: I really
see a lot of completely useless tags because they've been added
mindlessly, and they are nothing but an annoyance.

And if people who have real workflows that use Link tags actually were
to add them consciously, I wouldn't hate them so much.

So for example, people have mentioned amending patches (although most
people have actually mentioned amending the commit *message*, which
doesn't change the patch ID), and that's where inserting - as comments
- the lore links for the original commit could be a good idea.

Look, you can have a .git/hooks/prepare-commit-msg script that looks
something like this:

  #!/bin/sh
  COMMIT_MSG_FILE=$1
  COMMIT_SOURCE=$2
  SHA1=$3
  b4 dig -c "$SHA1" 2>&1 | sed 's/^/# /' >> "$COMMIT_MSG_FILE"

And lo and behold: you'll find the 'b4 dig' output at the end of your
commit message as you start editing it.

(The above script is "tested" in that I verified that yes

Ok, so the above is a really minimal hook, but I hope it gives people
ideas of how they can make things like Link tags work in a *conscious*
model, not a "mindlessly add them" model.

It's really the "add a flag to a config file and forget it, and now
every commit you do has a link tag whether you thought about it or
not" that I dislike so much.

             Linus

Re: Replacing Link trailers

[Linus Torvalds]

On Wed, 15 Oct 2025 at 12:15, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> (The above script is "tested" in that I verified that yes

.. premature 'hit send' situation. That should have said

 ..that yes] I verified that it superficially works, but didn't do
anything exhaustive.

It was obviously meant as a "look, you can do things like this", not
as a real fully fleshed out solution.

           Linus

Re: Replacing Link trailers

[Doug Anderson]

Hi,

On Wed, Oct 15, 2025 at 12:17 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, 15 Oct 2025 at 12:15, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > (The above script is "tested" in that I verified that yes
>
> .. premature 'hit send' situation. That should have said
>
>  ..that yes] I verified that it superficially works, but didn't do
> anything exhaustive.
>
> It was obviously meant as a "look, you can do things like this", not
> as a real fully fleshed out solution.

Just to be clear: this doesn't solve my problem because it relies on
_everyone else_ to change in a way that's much more complicated for
them. As Mark said, the person that needs to reference the "Link:" tag
(me / others replying here) is not the same as the person who needs to
add the "Link:" tag (maintainer). It was hard enough to convince
maintainers to make a tiny change to their workflow to add the "Link:"
tag in the first place. Convincing maintainers to add a complicated
git hook that only adds the link tag if it happens that the commit
"git patch-id" they're going to push doesn't match anything on the
mailing list? Yeah, no.

Given the number of people who have continued to reply to this thread
after the commit-hook suggestion you provided, I'm going to assume
that others agree that the git commit-hook is not a good solution to
the problem we're all trying to solve.

-Doug

Re: Replacing Link trailers

[Chen-Yu Tsai]

On Thu, Oct 16, 2025 at 6:51 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Oct 15, 2025 at 12:17 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Wed, 15 Oct 2025 at 12:15, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > >
> > > (The above script is "tested" in that I verified that yes
> >
> > .. premature 'hit send' situation. That should have said
> >
> >  ..that yes] I verified that it superficially works, but didn't do
> > anything exhaustive.
> >
> > It was obviously meant as a "look, you can do things like this", not
> > as a real fully fleshed out solution.
>
> Just to be clear: this doesn't solve my problem because it relies on
> _everyone else_ to change in a way that's much more complicated for
> them. As Mark said, the person that needs to reference the "Link:" tag
> (me / others replying here) is not the same as the person who needs to
> add the "Link:" tag (maintainer). It was hard enough to convince
> maintainers to make a tiny change to their workflow to add the "Link:"
> tag in the first place. Convincing maintainers to add a complicated
> git hook that only adds the link tag if it happens that the commit
> "git patch-id" they're going to push doesn't match anything on the
> mailing list? Yeah, no.

To add to that, this works precisely because the Link tag is added
"mindlessly" and "automatically" by b4 at the time the patch is
applied, pointing to the patch that was actually applied. If the
maintainer edits the commit, then they would add more notes in square
bracket form. Adding the Link tag requires almost no extra effort
from the maintainer if they are already using b4, except maybe
configuring it to use "patch.msgid.link" instead of "lore.kernel.org".

As many people have already said, the tag benefits not the maintainer
that applied the patch and added the tag, but other developers that
end up having to trace the history of a commit, be it for reporting
regressions or backporting / maintaining downstream or stable kernel
trees.

For reporting regressions the Link tag is very straightforward:
one bisects to a certain commit, writes an email replying to the given
Message-Id, and that's it. The person may optionally click on the link,
find that someone else has already reported the issue, and can either
just go about their own business, or add another report on top of it.

I've been on both sides, and I can say that the tag provides value to
people's workflows.


ChenYu

> Given the number of people who have continued to reply to this thread
> after the commit-hook suggestion you provided, I'm going to assume
> that others agree that the git commit-hook is not a good solution to
> the problem we're all trying to solve.
>
> -Doug
>

Re: Replacing Link trailers

[Greg KH]

On Wed, Oct 15, 2025 at 12:17:27PM -0700, Linus Torvalds wrote:
> On Wed, 15 Oct 2025 at 12:15, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > (The above script is "tested" in that I verified that yes
> 
> .. premature 'hit send' situation. That should have said
> 
>  ..that yes] I verified that it superficially works, but didn't do
> anything exhaustive.
> 
> It was obviously meant as a "look, you can do things like this", not
> as a real fully fleshed out solution.

So, to summarize all of this, you are suggesting that maintainers:
	- don't automatically include Link: tags when they don't touch a
	  patch and apply it directly from the email as `b4 dig` will be
	  able to find the patch.
	- if a maintainer does change a patch, add the Link: tag so that
	  people can find the original patch when looking it up later.

Is that correct?

If so, ugh, that just raised the workload of all of us maintainers as
now we have to remember to do that second step manually (or through the
new git hook, which will NOT work without a network connection so no
applying patches from planes or trains).

It also puts a burden on the "normal" person here, who took the time to
bisect a kernel bug, found a git commit and then needs to know who to
email about the thing.  That simple, dumb, extra, "Link:" tag provided
that context for them to be able to do that, and no user is going to
want to have to go install b4 to be able to figure that out.

I predict that maintainers are just going to drop the Link tag and not
remember to manually add it back, when touching patches, as that
increased their already-limited workload (and again, prevents from
applying patches without a good network connection).  And overall,
that's going to be a loss in our source history for people trying to
track down problems with changes in there.

The LF, many years ago, funded a tool to go and try to track all commits
back to the email that they came from, and it was a pain to do, and it
almost worked, but no one ever really used it.  But that little Link:
tag, _finally_ added by a huge majority of maintainers, made it dirt
simple for everyone to accurately track back the source of changes and
restart conversations trivially about bugs and issues found by users.

While I appreciate the goal of keeping our changelogs "crap free", I
still think that the "mindless Link: line" benefits far outweigh the
lack of it being there, and forcing us to use additional tools and
server resources, when doing our debugging and patch history tracing
work, which almost all users of the kernel source tree end up doing.

That single line is there for when we don't realize we are going to need
it in the future, think of it as an insurance tax.  It's saved me tons
of hours of time already in doing stable kernel work over the years, and
I'm sure it has helped others out as well, as I'm not alone in doing
backporting work to old codebases.

I'll miss it.

thanks,

greg k-h

Re: Replacing Link trailers

[Jani Nikula]

On Thu, 16 Oct 2025, Greg KH <gregkh@linuxfoundation.org> wrote:
> While I appreciate the goal of keeping our changelogs "crap free", I
> still think that the "mindless Link: line" benefits far outweigh the
> lack of it being there, and forcing us to use additional tools and
> server resources, when doing our debugging and patch history tracing
> work, which almost all users of the kernel source tree end up doing.
>
> That single line is there for when we don't realize we are going to need
> it in the future, think of it as an insurance tax.  It's saved me tons
> of hours of time already in doing stable kernel work over the years, and
> I'm sure it has helped others out as well, as I'm not alone in doing
> backporting work to old codebases.

For the parts of the drm subsystem that follow the maintainer/committer
model, the Link: trailer is also part of an audit trail, if you will,
that only patches actually posted on the list get committed and pushed.

"Something like this was once posted somewhere" is nowhere near the same
as "this is the exact patch, as part of this series".

For i915 and xe, you'll additionally find the CI results for the exact
patch/series, and passing result is part of the merge criteria.

BR,
Jani.

-- 
Jani Nikula, Intel

Re: Replacing Link trailers

[James Bottomley]

On Thu, 2025-10-16 at 08:57 +0200, Greg KH wrote:
> On Wed, Oct 15, 2025 at 12:17:27PM -0700, Linus Torvalds wrote:
> > On Wed, 15 Oct 2025 at 12:15, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > > 
> > > (The above script is "tested" in that I verified that yes
> > 
> > .. premature 'hit send' situation. That should have said
> > 
> >  ..that yes] I verified that it superficially works, but didn't do
> > anything exhaustive.
> > 
> > It was obviously meant as a "look, you can do things like this",
> > not as a real fully fleshed out solution.
> 
> So, to summarize all of this, you are suggesting that maintainers:
> 	- don't automatically include Link: tags when they don't
> touch a
> 	  patch and apply it directly from the email as `b4 dig`
> will be
> 	  able to find the patch.
> 	- if a maintainer does change a patch, add the Link: tag so
> that
> 	  people can find the original patch when looking it up
> later.
> 
> Is that correct?
> 
> If so, ugh, that just raised the workload of all of us maintainers as
> now we have to remember to do that second step manually (or through
> the new git hook, which will NOT work without a network connection so
> no applying patches from planes or trains).

I agree with all the complexity.  So why don't we simply have git am
add message-id to the commit header if it exists in the patch?  That
way every b4 generated commit will have a message-id header.  No-one
will ever see it unless they ask for the --pretty=raw (which is what
tools can do, so they'll all just work) and it is completely mindless
so everyone always knows what it points to if they want to dig it out.
b4 dig can even use it as the starting point to find the email.

Bonus: everyone is forced to use it (because it's built in to git) and
we always know exactly what it means: no debate about what the target
of the link should be.

Regards,

James

Re: Replacing Link trailers

[Greg KH]

On Thu, Oct 16, 2025 at 07:54:01AM -0400, James Bottomley wrote:
> On Thu, 2025-10-16 at 08:57 +0200, Greg KH wrote:
> > On Wed, Oct 15, 2025 at 12:17:27PM -0700, Linus Torvalds wrote:
> > > On Wed, 15 Oct 2025 at 12:15, Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > > 
> > > > (The above script is "tested" in that I verified that yes
> > > 
> > > .. premature 'hit send' situation. That should have said
> > > 
> > >  ..that yes] I verified that it superficially works, but didn't do
> > > anything exhaustive.
> > > 
> > > It was obviously meant as a "look, you can do things like this",
> > > not as a real fully fleshed out solution.
> > 
> > So, to summarize all of this, you are suggesting that maintainers:
> > 	- don't automatically include Link: tags when they don't
> > touch a
> > 	  patch and apply it directly from the email as `b4 dig`
> > will be
> > 	  able to find the patch.
> > 	- if a maintainer does change a patch, add the Link: tag so
> > that
> > 	  people can find the original patch when looking it up
> > later.
> > 
> > Is that correct?
> > 
> > If so, ugh, that just raised the workload of all of us maintainers as
> > now we have to remember to do that second step manually (or through
> > the new git hook, which will NOT work without a network connection so
> > no applying patches from planes or trains).
> 
> I agree with all the complexity.  So why don't we simply have git am
> add message-id to the commit header if it exists in the patch?

Where exactly would that be added?  Are you suggesting that git add a
new atom_type of ATOM_MESSAGEID or something like that?

If so, sure, that works for me, I just want a way to track back a commit
to a message somehow that does not require me to pick-and-choose when I
want to add that reference, as that increases the workload on
maintainers.  Be it a link: or a message-id, or something else that I
can "set and forget" in my git hooks and so can all other maintainers.

Then, sometime in the future, a user is happy that the maintainer "paid
the insurance bill" of adding that reference, so they can look up the
original commit as something went wrong.

Sounds like the networking maintainers also want it, as does drm.  I
think those are the two largest creators of commits in our tree these
days by far.  Luckily staging has died down so I'm no longer in that
category :)

thanks,

greg k-h




That
> way every b4 generated commit will have a message-id header.  No-one
> will ever see it unless they ask for the --pretty=raw (which is what
> tools can do, so they'll all just work) and it is completely mindless
> so everyone always knows what it points to if they want to dig it out.
> b4 dig can even use it as the starting point to find the email.
> 
> Bonus: everyone is forced to use it (because it's built in to git) and
> we always know exactly what it means: no debate about what the target
> of the link should be.
> 
> Regards,
> 
> James
> 
> 

Re: Replacing Link trailers

[James Bottomley]

On Thu, 2025-10-16 at 14:18 +0200, Greg KH wrote:
> On Thu, Oct 16, 2025 at 07:54:01AM -0400, James Bottomley wrote:
> > On Thu, 2025-10-16 at 08:57 +0200, Greg KH wrote:
> > > On Wed, Oct 15, 2025 at 12:17:27PM -0700, Linus Torvalds wrote:
> > > > On Wed, 15 Oct 2025 at 12:15, Linus Torvalds
> > > > <torvalds@linux-foundation.org> wrote:
> > > > > 
> > > > > (The above script is "tested" in that I verified that yes
> > > > 
> > > > .. premature 'hit send' situation. That should have said
> > > > 
> > > >  ..that yes] I verified that it superficially works, but didn't
> > > > do
> > > > anything exhaustive.
> > > > 
> > > > It was obviously meant as a "look, you can do things like
> > > > this",
> > > > not as a real fully fleshed out solution.
> > > 
> > > So, to summarize all of this, you are suggesting that
> > > maintainers:
> > > - don't automatically include Link: tags when they don't
> > > touch a
> > >   patch and apply it directly from the email as `b4 dig`
> > > will be
> > >   able to find the patch.
> > > - if a maintainer does change a patch, add the Link: tag so
> > > that
> > >   people can find the original patch when looking it up
> > > later.
> > > 
> > > Is that correct?
> > > 
> > > If so, ugh, that just raised the workload of all of us
> > > maintainers as now we have to remember to do that second step
> > > manually (or through the new git hook, which will NOT work
> > > without a network connection so no applying patches from planes
> > > or trains).
> > 
> > I agree with all the complexity.  So why don't we simply have git
> > am add message-id to the commit header if it exists in the patch?
> 
> Where exactly would that be added?  Are you suggesting that git add a
> new atom_type of ATOM_MESSAGEID or something like that?

Yes, I think so ... just looking at constructing a patch now.
Regardless of the outcome of this debate it seems like a reasonable
(and not kernel specific) feature to add to git.

I'm also looking in to adding a commit hook that might do the same
thing for the interim, but I don't think hooks can add headers (still
searching though).

> If so, sure, that works for me, I just want a way to track back a
> commit to a message somehow that does not require me to pick-and-
> choose when I want to add that reference, as that increases the
> workload on maintainers.  Be it a link: or a message-id, or something
> else that I can "set and forget" in my git hooks and so can all other
> maintainers.

I get that. I actually think this debate should be split into two
pieces:

   1. What completely automated thing do we need to help tools with
      tracking.  I think the message-id header would do that
   2. What mindful thing could maintainers add to a commit to give
      useful background information?

I think a lot of people want the former but Linus is asking for the
latter and Link: has previously tried to serve both purposes which lead
to the current dispute. I'm hoping splitting the discussion will
produce something better on both fronts.

So to reiterate this proposal is only for 1. we should still debate
what would be useful to add for more information that humans can
consume and when should it be added.

Regards,

James

Re: Replacing Link trailers

[Konstantin Ryabitsev]

On Thu, Oct 16, 2025 at 08:29:01AM -0400, James Bottomley wrote:
> > Where exactly would that be added?  Are you suggesting that git add a
> > new atom_type of ATOM_MESSAGEID or something like that?
> 
> Yes, I think so ... just looking at constructing a patch now.
> Regardless of the outcome of this debate it seems like a reasonable
> (and not kernel specific) feature to add to git.

I am wholeheartedly for this approach. One of the downsides of the current
scheme is that Link: trailers can be pointing at multiple patch submissions
(e.g. if the commit wants to highlight a related patch series), so without a
clear indication which link is the provenance link, we still have potential
for confusion.

I recommend that we all stop beating the Link: trailer topic and sit on our
hands until the above is either accepted or rejected by the git maintainers.

IOW:

- Keep current "mindless" Link: approach, with the patch.msgid.link domain for
  automatically-added Link: trailers. It mitigates the problem of Linus
  getting annoyed at the ambiguity, but keeps things working for maintainers
  who are already dependent on these links being present.

- Work with git maintainers to add commit provenance information into the
  commit headers.

- Reconvene at the upcoming maintainer summit to hammer out whatever remains
  of the discussion.


Would that work for everyone?

-K

Re: Replacing Link trailers

[Steven Rostedt]

On Thu, 16 Oct 2025 09:00:49 -0400
Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

> I am wholeheartedly for this approach. One of the downsides of the current
> scheme is that Link: trailers can be pointing at multiple patch submissions
> (e.g. if the commit wants to highlight a related patch series), so without a
> clear indication which link is the provenance link, we still have potential
> for confusion.

I started to separate out "Link:" that was meaningful to the conversation
from "Link:" that was a patch submission, not by the URL but by having the
meaningful ones outside of the tags section. As to me, if it is for human
consumption, it shouldn't be part of the tags.

For example:

    tracing: Have eprobes have their own config option
    
    Eprobes were added in 5.15 and were selected whenever any of the other
    probe events were selected. If kprobe events were enabled (which it is by
    default if kprobes are enabled) it would enable eprobe events as well. The
    same for uprobes and fprobes.
    
    Have eprobes have its own config and it gets enabled by default if tracing
    is enabled.
    
    Link: https://lore.kernel.org/all/20250729102636.b7cce553e7cc263722b12365@kernel.org/
    
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Link: https://lore.kernel.org/20250730140945.360286733@kernel.org
    Suggested-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>

That first link is the reason for the patch, whereas the one in the tags
links back to the patch itself and was automated. If there was a discussion
during the patch submission, I don't separate it. As that would take extra
work ;-)

-- Steve

Re: Replacing Link trailers

[Mark Brown]

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

On Thu, Oct 16, 2025 at 09:00:49AM -0400, Konstantin Ryabitsev wrote:

> I recommend that we all stop beating the Link: trailer topic and sit on our
> hands until the above is either accepted or rejected by the git maintainers.

> IOW:

> - Keep current "mindless" Link: approach, with the patch.msgid.link domain for
>   automatically-added Link: trailers. It mitigates the problem of Linus
>   getting annoyed at the ambiguity, but keeps things working for maintainers
>   who are already dependent on these links being present.

> - Work with git maintainers to add commit provenance information into the
>   commit headers.

> - Reconvene at the upcoming maintainer summit to hammer out whatever remains
>   of the discussion.

> Would that work for everyone?

This seems sensible to me.

I will note that as a Debian stable user I'm expecting to get a new
version of git in roughly 2027, though I imagine there will be backports
available.

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

Re: Replacing Link trailers

[Rob Herring]

On Thu, Oct 16, 2025 at 8:02 AM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> On Thu, Oct 16, 2025 at 08:29:01AM -0400, James Bottomley wrote:
> > > Where exactly would that be added?  Are you suggesting that git add a
> > > new atom_type of ATOM_MESSAGEID or something like that?
> >
> > Yes, I think so ... just looking at constructing a patch now.
> > Regardless of the outcome of this debate it seems like a reasonable
> > (and not kernel specific) feature to add to git.
>
> I am wholeheartedly for this approach. One of the downsides of the current
> scheme is that Link: trailers can be pointing at multiple patch submissions
> (e.g. if the commit wants to highlight a related patch series), so without a
> clear indication which link is the provenance link, we still have potential
> for confusion.
>
> I recommend that we all stop beating the Link: trailer topic and sit on our
> hands until the above is either accepted or rejected by the git maintainers.

git-am already supports adding message-ID though to the commit msg
rather than the commit itself. A custom pager config could either hide
it or transform it into a lore link. That would avoid the need to wait
for a new git version to trickle out to everyone.

With a new atom_type, there doesn't seem to be a simple way to turn on
or off a field in git-log. We'd need '--pretty=linus' or some new git
config setting.

Rob

Re: Replacing Link trailers

[James Bottomley]

On Thu, 2025-10-16 at 09:58 -0500, Rob Herring wrote:
[...]
> With a new atom_type, there doesn't seem to be a simple way to turn
> on or off a field in git-log. We'd need '--pretty=linus' or some new
> git config setting.

Well, not on a per field basis, no.  --pretty=raw will give you
everything, though and "grep ^message-id" would pull it out, which I
think would work for scripts.  If humans want to use it, I think, per
Linus, we'd have some option to convert it to a clickable something.

Regards,

James

Re: Replacing Link trailers

[Geert Uytterhoeven]

Hi James,

On Thu, 16 Oct 2025 at 17:07, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Thu, 2025-10-16 at 09:58 -0500, Rob Herring wrote:
> [...]
> > With a new atom_type, there doesn't seem to be a simple way to turn
> > on or off a field in git-log. We'd need '--pretty=linus' or some new
> > git config setting.
>
> Well, not on a per field basis, no.  --pretty=raw will give you
> everything, though and "grep ^message-id" would pull it out, which I
> think would work for scripts.  If humans want to use it, I think, per
> Linus, we'd have some option to convert it to a clickable something.

Let's hope bug reporters who barely learnt how to run git bisect will
manage to find it...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Replacing Link trailers

[James Bottomley]

On Thu, 2025-10-16 at 17:36 +0200, Geert Uytterhoeven wrote:
> Hi James,
> 
> On Thu, 16 Oct 2025 at 17:07, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Thu, 2025-10-16 at 09:58 -0500, Rob Herring wrote:
> > [...]
> > > With a new atom_type, there doesn't seem to be a simple way to
> > > turn on or off a field in git-log. We'd need '--pretty=linus' or
> > > some new git config setting.
> > 
> > Well, not on a per field basis, no.  --pretty=raw will give you
> > everything, though and "grep ^message-id" would pull it out, which
> > I think would work for scripts.  If humans want to use it, I think,
> > per Linus, we'd have some option to convert it to a clickable
> > something.
> 
> Let's hope bug reporters who barely learnt how to run git bisect will
> manage to find it...

Do those type of bug reporters even know how to use Link: today?  But
regardless the point of this is to solve the tooling mechanical issue,
not to build something that should be visible to everyone.  As I said,
if we split the discussion into the mechanical do for everything part
(which this is) the rest is a discussion of what additional information
and how should we add to the commit body.

Regards,

James

Re: Replacing Link trailers

[Steven Rostedt]

On Thu, 16 Oct 2025 11:07:40 -0400
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> On Thu, 2025-10-16 at 09:58 -0500, Rob Herring wrote:
> [...]
> > With a new atom_type, there doesn't seem to be a simple way to turn
> > on or off a field in git-log. We'd need '--pretty=linus' or some new
> > git config setting.  
> 
> Well, not on a per field basis, no.  --pretty=raw will give you
> everything, though and "grep ^message-id" would pull it out, which I
> think would work for scripts.  If humans want to use it, I think, per
> Linus, we'd have some option to convert it to a clickable something.

It would be also nice to see it in the comment section of a git commit.

The part after:

  # Please enter the commit message for your changes. Lines starting
  # with '#' will be ignored, and an empty message aborts the commit.

-- Steve

Re: Replacing Link trailers

[H. Peter Anvin]

On October 16, 2025 7:58:16 AM PDT, Rob Herring <robherring2@gmail.com> wrote:
>On Thu, Oct 16, 2025 at 8:02 AM Konstantin Ryabitsev
><konstantin@linuxfoundation.org> wrote:
>>
>> On Thu, Oct 16, 2025 at 08:29:01AM -0400, James Bottomley wrote:
>> > > Where exactly would that be added?  Are you suggesting that git add a
>> > > new atom_type of ATOM_MESSAGEID or something like that?
>> >
>> > Yes, I think so ... just looking at constructing a patch now.
>> > Regardless of the outcome of this debate it seems like a reasonable
>> > (and not kernel specific) feature to add to git.
>>
>> I am wholeheartedly for this approach. One of the downsides of the current
>> scheme is that Link: trailers can be pointing at multiple patch submissions
>> (e.g. if the commit wants to highlight a related patch series), so without a
>> clear indication which link is the provenance link, we still have potential
>> for confusion.
>>
>> I recommend that we all stop beating the Link: trailer topic and sit on our
>> hands until the above is either accepted or rejected by the git maintainers.
>
>git-am already supports adding message-ID though to the commit msg
>rather than the commit itself. A custom pager config could either hide
>it or transform it into a lore link. That would avoid the need to wait
>for a new git version to trickle out to everyone.
>
>With a new atom_type, there doesn't seem to be a simple way to turn on
>or off a field in git-log. We'd need '--pretty=linus' or some new git
>config setting.
>
>Rob
>
>

The Message-ID is largely useless without a List-ID at least, and if the maintainer picks it up directly then they will never see the List-ID and would have to add it manually. 

Re: Replacing Link trailers

[James Bottomley]

On Thu, 2025-10-16 at 12:29 -0700, H. Peter Anvin wrote:
[...]
> The Message-ID is largely useless without a List-ID at least, and if
> the maintainer picks it up directly then they will never see the
> List-ID and would have to add it manually. 

Not really in the modern age.  Lore would always be my first choice
because it doesn't need to know the list to resolve if it's archived
the message, but even if that turns up nothing, a search engine should
be able to index it (well, eventually, it seems to take them a few
days).

Regards,

James

Re: Replacing Link trailers

[H. Peter Anvin]

On October 16, 2025 12:32:48 PM PDT, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>On Thu, 2025-10-16 at 12:29 -0700, H. Peter Anvin wrote:
>[...]
>> The Message-ID is largely useless without a List-ID at least, and if
>> the maintainer picks it up directly then they will never see the
>> List-ID and would have to add it manually. 
>
>Not really in the modern age.  Lore would always be my first choice
>because it doesn't need to know the list to resolve if it's archived
>the message, but even if that turns up nothing, a search engine should
>be able to index it (well, eventually, it seems to take them a few
>days).
>
>Regards,
>
>James
>
>

But as Linus has pointed out: it shifts the workload to the user, where it is less amenable to automation.

Re: Replacing Link trailers

[James Bottomley]

On Thu, 2025-10-16 at 09:00 -0400, Konstantin Ryabitsev wrote:
> On Thu, Oct 16, 2025 at 08:29:01AM -0400, James Bottomley wrote:
> > > Where exactly would that be added?  Are you suggesting that git
> > > add a new atom_type of ATOM_MESSAGEID or something like that?
> > 
> > Yes, I think so ... just looking at constructing a patch now.
> > Regardless of the outcome of this debate it seems like a reasonable
> > (and not kernel specific) feature to add to git.
> 
> I am wholeheartedly for this approach. One of the downsides of the
> current scheme is that Link: trailers can be pointing at multiple
> patch submissions (e.g. if the commit wants to highlight a related
> patch series), so without a clear indication which link is the
> provenance link, we still have potential for confusion.
> 
> I recommend that we all stop beating the Link: trailer topic and sit
> on our hands until the above is either accepted or rejected by the
> git maintainers.

Since Linus' intervention this may be unnecessary, but I've sent the
patch anyway.  I think it's a useful update to git for other projects
and, if it gets accepted, we could still switch over to this in future
if for no other reason than to unclutter the trailers a bit.

https://lore.kernel.org/git/20251016185758.21996-1-James.Bottomley@HansenPartnership.com

Regards,

James

Re: Replacing Link trailers

[Doug Anderson]

Hi,

On Thu, Oct 16, 2025 at 12:09 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Since Linus' intervention this may be unnecessary,

Thanks to a tip from LWN, connecting this thread to the other
centithread on Link tags. Presumably this is what James meant about
"Linus' intervention"?

Link: https://lore.kernel.org/all/CAHk-=wj5MATvT-FR8qNpXuuBGiJdjY1kRfhtzuyBSpTKR+=Vtw@mail.gmail.com/

As per standard Linux practices, please don't submit anything to
"Documentation" about this. Anyone who needs to know should be able to
find the current policy about Link: tags in the middle of a random
centithread. ;-) "Use the <mailing lists>, Luke." ;-)

-Doug

Re: Replacing Link trailers

[Vlastimil Babka]

On 10/17/25 04:27, Doug Anderson wrote:
> Hi,
> 
> On Thu, Oct 16, 2025 at 12:09 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
>>
>> Since Linus' intervention this may be unnecessary,
> 
> Thanks to a tip from LWN, connecting this thread to the other
> centithread on Link tags. Presumably this is what James meant about
> "Linus' intervention"?
> 
> Link: https://lore.kernel.org/all/CAHk-=wj5MATvT-FR8qNpXuuBGiJdjY1kRfhtzuyBSpTKR+=Vtw@mail.gmail.com/
> 
> As per standard Linux practices, please don't submit anything to
> "Documentation" about this. Anyone who needs to know should be able to
> find the current policy about Link: tags in the middle of a random
> centithread. ;-) "Use the <mailing lists>, Luke." ;-)

The documentation has existed for a while in
Documentation/process/maintainer-tip.rst

   You can also use ``Link:`` trailers to indicate the origin of the
   patch when applying it to your git tree. In that case, please use the
   dedicated ``patch.msgid.link`` domain instead of ``lore.kernel.org``.
   This practice makes it possible for automated tooling to identify
   which link to use to retrieve the original patch submission. For
   example::

     Link: https://patch.msgid.link/patch-source-message-id@here

Since that file is strictly speaking about the tip tree, it would make sense
to promote it to something more generic?


> -Doug
> 

Re: Replacing Link trailers

[Geert Uytterhoeven]

Hi Vlastimil,

On Fri, 17 Oct 2025 at 10:44, Vlastimil Babka <vbabka@suse.cz> wrote:
> On 10/17/25 04:27, Doug Anderson wrote:
> > On Thu, Oct 16, 2025 at 12:09 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> >>
> >> Since Linus' intervention this may be unnecessary,
> >
> > Thanks to a tip from LWN, connecting this thread to the other
> > centithread on Link tags. Presumably this is what James meant about
> > "Linus' intervention"?
> >
> > Link: https://lore.kernel.org/all/CAHk-=wj5MATvT-FR8qNpXuuBGiJdjY1kRfhtzuyBSpTKR+=Vtw@mail.gmail.com/
> >
> > As per standard Linux practices, please don't submit anything to
> > "Documentation" about this. Anyone who needs to know should be able to
> > find the current policy about Link: tags in the middle of a random
> > centithread. ;-) "Use the <mailing lists>, Luke." ;-)
>
> The documentation has existed for a while in
> Documentation/process/maintainer-tip.rst
>
>    You can also use ``Link:`` trailers to indicate the origin of the
>    patch when applying it to your git tree. In that case, please use the
>    dedicated ``patch.msgid.link`` domain instead of ``lore.kernel.org``.
>    This practice makes it possible for automated tooling to identify
>    which link to use to retrieve the original patch submission. For
>    example::
>
>      Link: https://patch.msgid.link/patch-source-message-id@here
>
> Since that file is strictly speaking about the tip tree, it would make sense
> to promote it to something more generic?

That existed, too, but was removed in commit 944df7a31452f75b ("docs:
update the guidance for Link: tags") in v6.18-rc1.  That commit carries
a non-clickable Message-ID:-tag instead, and does not apply to Chinese
readers ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Replacing Link trailers

[Rafael J. Wysocki]

On Fri, Oct 17, 2025 at 11:31 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Vlastimil,
>
> On Fri, 17 Oct 2025 at 10:44, Vlastimil Babka <vbabka@suse.cz> wrote:
> > On 10/17/25 04:27, Doug Anderson wrote:
> > > On Thu, Oct 16, 2025 at 12:09 PM James Bottomley
> > > <James.Bottomley@hansenpartnership.com> wrote:
> > >>
> > >> Since Linus' intervention this may be unnecessary,
> > >
> > > Thanks to a tip from LWN, connecting this thread to the other
> > > centithread on Link tags. Presumably this is what James meant about
> > > "Linus' intervention"?
> > >
> > > Link: https://lore.kernel.org/all/CAHk-=wj5MATvT-FR8qNpXuuBGiJdjY1kRfhtzuyBSpTKR+=Vtw@mail.gmail.com/
> > >
> > > As per standard Linux practices, please don't submit anything to
> > > "Documentation" about this. Anyone who needs to know should be able to
> > > find the current policy about Link: tags in the middle of a random
> > > centithread. ;-) "Use the <mailing lists>, Luke." ;-)
> >
> > The documentation has existed for a while in
> > Documentation/process/maintainer-tip.rst
> >
> >    You can also use ``Link:`` trailers to indicate the origin of the
> >    patch when applying it to your git tree. In that case, please use the
> >    dedicated ``patch.msgid.link`` domain instead of ``lore.kernel.org``.
> >    This practice makes it possible for automated tooling to identify
> >    which link to use to retrieve the original patch submission. For
> >    example::
> >
> >      Link: https://patch.msgid.link/patch-source-message-id@here
> >
> > Since that file is strictly speaking about the tip tree, it would make sense
> > to promote it to something more generic?
>
> That existed, too, but was removed in commit 944df7a31452f75b ("docs:
> update the guidance for Link: tags") in v6.18-rc1.  That commit carries
> a non-clickable Message-ID:-tag instead, and does not apply to Chinese
> readers ;-)

So I guess it can be restored in a more generic form (maybe along with
some specific examples of what that information is used for), but
instead of saying "In that case, please use the dedicated
``patch.msgid.link`` domain instead of ``lore.kernel.org``", I would
say "In that case, the dedicated ``patch.msgid.link`` domain must be
used instead of ``lore.kernel.org``".

Re: Replacing Link trailers

[Mathieu Desnoyers]

On 2025-10-16 08:18, Greg KH wrote:
[...]
> Be it a link: or a message-id, or something else that I
> can "set and forget" in my git hooks and so can all other maintainers.

I can't help but keep thinking that we are trying to solve a problem
that is fundamentally just about namespacing with needlessly complex
technical solutions that will degrade the workflow of many maintainers
across the span of the entire Linux software development process.

The "Link:" tag is unfortunately a bag of holding for all sorts of
links. So if Linus interprets the "Link:" tag as a link to relevant
URLs with an implied meaning "see also" or "more relevant info
here", then whatever else gets added under "Link:" with a different
purpose is seen as noise.

One possible solution would be to introduce a new tag such as
"Link-Origin: https://..." or just "Origin: https://..." or
whatever better name we can collectively come up with.

That way the semantic should be obvious to everyone.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Re: Replacing Link trailers

[Mark Brown]

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

On Thu, Oct 16, 2025 at 08:34:59AM -0400, Mathieu Desnoyers wrote:

> The "Link:" tag is unfortunately a bag of holding for all sorts of
> links. So if Linus interprets the "Link:" tag as a link to relevant
> URLs with an implied meaning "see also" or "more relevant info
> here", then whatever else gets added under "Link:" with a different
> purpose is seen as noise.

> One possible solution would be to introduce a new tag such as
> "Link-Origin: https://..." or just "Origin: https://..." or
> whatever better name we can collectively come up with.

> That way the semantic should be obvious to everyone.

As mentioned in other threads the goal with using patch.msgid.link as
the domain for the simple list archive links was basically that, to
provide an easy way to identify through simple inspection that this is
just a link to the original patch.  It does have the advantage of
already being fairly widely deployed.

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

Re: Replacing Link trailers

[Geert Uytterhoeven]

Hi Matthieu,

On Thu, 16 Oct 2025 at 14:35, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
> On 2025-10-16 08:18, Greg KH wrote:
> [...]
> > Be it a link: or a message-id, or something else that I
> > can "set and forget" in my git hooks and so can all other maintainers.
>
> I can't help but keep thinking that we are trying to solve a problem
> that is fundamentally just about namespacing with needlessly complex
> technical solutions that will degrade the workflow of many maintainers
> across the span of the entire Linux software development process.
>
> The "Link:" tag is unfortunately a bag of holding for all sorts of
> links. So if Linus interprets the "Link:" tag as a link to relevant
> URLs with an implied meaning "see also" or "more relevant info
> here", then whatever else gets added under "Link:" with a different
> purpose is seen as noise.
>
> One possible solution would be to introduce a new tag such as
> "Link-Origin: https://..." or just "Origin: https://..." or
> whatever better name we can collectively come up with.
>
> That way the semantic should be obvious to everyone.

We already have a way to distinguish:
  - "Link: https://patch.msgid.link/... " for the original patch email,
  - "Link: https://lore.kernel.org/..." for e.g. the big upfront design
    discussion.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Replacing Link trailers

[Mathieu Desnoyers]

On 2025-10-16 08:49, Geert Uytterhoeven wrote:
> Hi Matthieu,
> 
> On Thu, 16 Oct 2025 at 14:35, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
>> On 2025-10-16 08:18, Greg KH wrote:
>> [...]
>>> Be it a link: or a message-id, or something else that I
>>> can "set and forget" in my git hooks and so can all other maintainers.
>>
>> I can't help but keep thinking that we are trying to solve a problem
>> that is fundamentally just about namespacing with needlessly complex
>> technical solutions that will degrade the workflow of many maintainers
>> across the span of the entire Linux software development process.
>>
>> The "Link:" tag is unfortunately a bag of holding for all sorts of
>> links. So if Linus interprets the "Link:" tag as a link to relevant
>> URLs with an implied meaning "see also" or "more relevant info
>> here", then whatever else gets added under "Link:" with a different
>> purpose is seen as noise.
>>
>> One possible solution would be to introduce a new tag such as
>> "Link-Origin: https://..." or just "Origin: https://..." or
>> whatever better name we can collectively come up with.
>>
>> That way the semantic should be obvious to everyone.
> 
> We already have a way to distinguish:
>    - "Link: https://patch.msgid.link/... " for the original patch email,
>    - "Link: https://lore.kernel.org/..." for e.g. the big upfront design
>      discussion.

What I'm trying to figure out here is whether Linus is aware of this
implied namespacing within the URL, and if we can improve the
situation by lifting the namespacing to the level of the "Link:"
tag rather than hide it under an implied semantic within the URL.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Re: Replacing Link trailers

[Geert Uytterhoeven]

Hi Matthieu,

On Thu, 16 Oct 2025 at 14:54, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
> On 2025-10-16 08:49, Geert Uytterhoeven wrote:
> > On Thu, 16 Oct 2025 at 14:35, Mathieu Desnoyers
> > <mathieu.desnoyers@efficios.com> wrote:
> >> On 2025-10-16 08:18, Greg KH wrote:
> >> [...]
> >>> Be it a link: or a message-id, or something else that I
> >>> can "set and forget" in my git hooks and so can all other maintainers.
> >>
> >> I can't help but keep thinking that we are trying to solve a problem
> >> that is fundamentally just about namespacing with needlessly complex
> >> technical solutions that will degrade the workflow of many maintainers
> >> across the span of the entire Linux software development process.
> >>
> >> The "Link:" tag is unfortunately a bag of holding for all sorts of
> >> links. So if Linus interprets the "Link:" tag as a link to relevant
> >> URLs with an implied meaning "see also" or "more relevant info
> >> here", then whatever else gets added under "Link:" with a different
> >> purpose is seen as noise.
> >>
> >> One possible solution would be to introduce a new tag such as
> >> "Link-Origin: https://..." or just "Origin: https://..." or
> >> whatever better name we can collectively come up with.
> >>
> >> That way the semantic should be obvious to everyone.
> >
> > We already have a way to distinguish:
> >    - "Link: https://patch.msgid.link/... " for the original patch email,
> >    - "Link: https://lore.kernel.org/..." for e.g. the big upfront design
> >      discussion.
>
> What I'm trying to figure out here is whether Linus is aware of this
> implied namespacing within the URL, and if we can improve the
> situation by lifting the namespacing to the level of the "Link:"
> tag rather than hide it under an implied semantic within the URL.

I assume so, as AFAIK it was created exactly for this.
Oldest reference I could find:
https://lore.kernel.org/all/20240617-arboreal-industrious-hedgehog-5b84ae@meerkat/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Replacing Link trailers

[Jiri Kosina]

On Thu, 16 Oct 2025, Mathieu Desnoyers wrote:

> The "Link:" tag is unfortunately a bag of holding for all sorts of
> links.

That's indeed the case.

People are using Link: not only to refer to the actual msgid that was used 
to apply the patch , then there are links to all sorts of bugzillas, 
github pull requests, gitlab issue reports, ... and those definitely have 
completely different semantics.

Which is also why people sometimes seem to be talking past each other, 
because maintainers mostly see it as a primary tool to reference the email 
thread that was the source of the patch, while submitters often see it as 
a way to express "See also for random pile of other information 
regarding this".

But I think it's an important disctinction.

-- 
Jiri Kosina
SUSE Labs

Re: Replacing Link trailers

[James Bottomley]

On Thu, 2025-10-16 at 14:51 +0200, Jiri Kosina wrote:
> On Thu, 16 Oct 2025, Mathieu Desnoyers wrote:
> 
> > The "Link:" tag is unfortunately a bag of holding for all sorts of
> > links.
> 
> That's indeed the case.
> 
> People are using Link: not only to refer to the actual msgid that was
> used to apply the patch , then there are links to all sorts of
> bugzillas, github pull requests, gitlab issue reports, ... and those
> definitely have completely different semantics.
> 
> Which is also why people sometimes seem to be talking past each
> other, because maintainers mostly see it as a primary tool to
> reference the email thread that was the source of the patch, while
> submitters often see it as a way to express "See also for random pile
> of other information regarding this".
> 
> But I think it's an important disctinction.

To repeat what I said here:
https://lore.kernel.org/ksummit/ef52db7e1d08eb03376fd9343c965aab4dc71ce5.camel@HansenPartnership.com/

---
I actually think this debate should be split into two
pieces:

   1. What completely automated thing do we need to help tools with
      tracking.  I think the message-id header would do that
   2. What mindful thing could maintainers add to a commit to give
      useful background information?

I think a lot of people want the former but Linus is asking for the
latter and Link: has previously tried to serve both purposes which lead
to the current dispute. I'm hoping splitting the discussion will
produce something better on both fronts.
---

Regards,

James

Re: Replacing Link trailers

[Steven Rostedt]

On Thu, 16 Oct 2025 08:54:26 -0400
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> ---
> I actually think this debate should be split into two
> pieces:
> 
>    1. What completely automated thing do we need to help tools with
>       tracking.  I think the message-id header would do that
>    2. What mindful thing could maintainers add to a commit to give
>       useful background information?
> 
> I think a lot of people want the former but Linus is asking for the
> latter and Link: has previously tried to serve both purposes which lead
> to the current dispute. I'm hoping splitting the discussion will
> produce something better on both fronts.
> ---


As I just replied to Konstantin, I do 1 via my automated scripts that puts
the link into the tags section, and 2 by placing the link outside the tags
section as it is meaningful for humans to read.

I will note, that I do not add 2 when a good discussion happened during a
patch submission. I only add 2 when another discussion lead to the patch
creation. 1 is for seeing if a discussion happened during patch submission
or not.

-- Steve

Re: Replacing Link trailers

[Michael S. Tsirkin]

On Thu, Oct 16, 2025 at 07:54:01AM -0400, James Bottomley wrote:
> On Thu, 2025-10-16 at 08:57 +0200, Greg KH wrote:
> > On Wed, Oct 15, 2025 at 12:17:27PM -0700, Linus Torvalds wrote:
> > > On Wed, 15 Oct 2025 at 12:15, Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > > 
> > > > (The above script is "tested" in that I verified that yes
> > > 
> > > .. premature 'hit send' situation. That should have said
> > > 
> > >  ..that yes] I verified that it superficially works, but didn't do
> > > anything exhaustive.
> > > 
> > > It was obviously meant as a "look, you can do things like this",
> > > not as a real fully fleshed out solution.
> > 
> > So, to summarize all of this, you are suggesting that maintainers:
> > 	- don't automatically include Link: tags when they don't
> > touch a
> > 	  patch and apply it directly from the email as `b4 dig`
> > will be
> > 	  able to find the patch.
> > 	- if a maintainer does change a patch, add the Link: tag so
> > that
> > 	  people can find the original patch when looking it up
> > later.
> > 
> > Is that correct?
> > 
> > If so, ugh, that just raised the workload of all of us maintainers as
> > now we have to remember to do that second step manually (or through
> > the new git hook, which will NOT work without a network connection so
> > no applying patches from planes or trains).
> 
> I agree with all the complexity.  So why don't we simply have git am
> add message-id to the commit header if it exists in the patch?  That
> way every b4 generated commit will have a message-id header.  No-one
> will ever see it unless they ask for the --pretty=raw (which is what
> tools can do, so they'll all just work) and it is completely mindless
> so everyone always knows what it points to if they want to dig it out.
> b4 dig can even use it as the starting point to find the email.
> 
> Bonus: everyone is forced to use it (because it's built in to git) and
> we always know exactly what it means: no debate about what the target
> of the link should be.
> 
> Regards,
> 
> James

Or a "log filter" flag to make git log
- hide message id tag in the commit log - for those that hate it
- convert it to lore links - for those that want it clickable



-- 
MST

Re: Replacing Link trailers

[Steven Rostedt]

On Thu, 16 Oct 2025 08:57:23 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:

> I predict that maintainers are just going to drop the Link tag and not
> remember to manually add it back, when touching patches, as that
> increased their already-limited workload (and again, prevents from
> applying patches without a good network connection).  And overall,
> that's going to be a loss in our source history for people trying to
> track down problems with changes in there.

This!

I already said that if I have to remove the "useless" links, I'm not going
to add any links. I do this and the daisy chain because others have told me
it's useful. If I have to do manual work for something I don't use, why
should I bother? Like Linus, if it doesn't work for him, why should I do
extra work at every commit so that it's useful for others, when currently
it's automatically added by my scripts?

-- Steve

Re: Replacing Link trailers

[Kees Cook]

On Wed, Oct 15, 2025 at 12:15:09PM -0700, Linus Torvalds wrote:
> Look, you can have a .git/hooks/prepare-commit-msg script that looks
> something like this:
> 
>   #!/bin/sh
>   COMMIT_MSG_FILE=$1
>   COMMIT_SOURCE=$2
>   SHA1=$3
>   b4 dig -c "$SHA1" 2>&1 | sed 's/^/# /' >> "$COMMIT_MSG_FILE"
> 
> And lo and behold: you'll find the 'b4 dig' output at the end of your
> commit message as you start editing it.

Perhaps use local git notes (or whatever) for the "b4 am" URL (that would
have been the Link tag), and at commit-msg time (i.e. the above hook),
if "b4 dig" doesn't match that URL, emit the saved Link tag and a FIXME
into the commit msg to describe what changed enough that "b4 dig" didn't
find it and why a Link tag is now justified?

-- 
Kees Cook

Re: Replacing Link trailers

[Mark Brown]

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

On Wed, Oct 15, 2025 at 12:15:09PM -0700, Linus Torvalds wrote:

> And if people who have real workflows that use Link tags actually were
> to add them consciously, I wouldn't hate them so much.

Where people are adding the tags as a matter of routine it's commonly
because others find it useful to have them rather than for their own
direct benefit, the workflow is someone else's.  People come along later
and want to follow the trail back from git to the mailing list - for
example my main use case is that I've got a bisected test failure and
want to tell someone who might care about it while also checking to see
if the issue has already been reported.  Sure, dig will work for that
most of the time but it's heuristic based and it's something people have
to install.  

I happen to already have tip of tree b4 to hand anyway for other reasons
so it's a relatively small speedbump for me personally but it's hard to
get enthusiastic about.


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