Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)

[Vlastimil Babka <vbabka@suse.cz>]

On 9/9/25 16:42, Konstantin Ryabitsev wrote:
> On Tue, Sep 09, 2025 at 08:35:18AM -0600, Jens Axboe wrote:
>> >> On a global scale, that's quite a number of saved mailing list archive searches.
>> > 
>> > +1 FWIW. I also started slapping the links on all patches in a series,
>> > even if we apply with a merge commit. I don't know of a good way with
>> > git to "get to the first parent merge" so scanning the history to find
>> > the link in the cover letter was annoying me :(
>> 
>> Like I've tried to argue, I find them useful too. But after this whole
>> mess of a thread, I killed -l from my scripts. I do think it's a mistake
>> and it seems like the only reason to remove them is that Linus expects
>> to find something at the end of the link rainbow and is often
>> disappointed, and that annoys him enough to rant about it.
>> 
>> I know some folks downstream of me on the io_uring side find them useful
>> too, because they've asked me several times to please remember to ensure
>> my own self-applied patches have the link as well. For those, I tend to
>> pick or add them locally rather than use b4 for it, which is why they've
>> never had links.
>> 
>> As far as I can tell, only two things have been established here:
>> 
>> 1) Linus hates the Link tags, except if they have extra information
>> 2) Lots of other folks find them useful
>> 
>> and hence we're at a solid deadlock here.
> 
> I did suggest that provenance links use the patch.msgid.link subdomain. This

Yes, and the PR that started this thread had a normal lore link. Would it
have been different with a patch.msgid.link as perhaps Linus would not try
opening it and become disappointed?
You did kinda ask that early in the thread but then the conversation went in
different directions.

> should clearly mark it as the source of the patch and not any other
> discussion. I think this is a reasonable compromise that will only mildly
> annoy Linus but let subsystems relying on these links continue to use them.
> 
> -K
>