#Linux 6.17-rc5 is out:

https://lore.kernel.org/lkml/CAHk-=wh5AyuvEhNY9a57v-vwyr7EkPVRUKMPwj92yF_K0dJHVg@mail.gmail.com/

""Things remain normal - both the diffstat and the commit counts look entirely sane. […]

The one discussion that I was part of that happened last week that might be worth mentioning is that I've been complaining for years about useless "Link:" entries in commit messages that don't point to any new information. […] if that link ends up being just a pointer to the email that became that commit - with nothing else - that allegedly helpful link only added human cost for me.

The same ends up being true when chasing down bug reports.

So please: don't add useless information to commits in general, but in _particular_ don't add "Link:" tags that only point back to the original submission email. […]

Make the links be something *useful*. Make them point to the report for the bug that was the cause of the commit. Make them point to the discussion that explains the impetus for the commit. […]

Make "Link:" tags be something to celebrate, not something to curse because they are worthless and waste peoples time.

Please?

Linus""

#kernel #LinuxKernel

2/ FWIW, here is another quote from the #Linux 6.17-rc5 announcement:

""I'd claim that it's all small patches, but we do have one larger one: the DLink/Sundance driver was resurrected [after being removed for 6.13-rc1], so in between all the one- and few-liners, there's a revert that brings back 2k lines in the form that driver.""

For more details, see https://git.kernel.org/torvalds/c/8b3332c1331c7c260bdff89bfdfd24ea263be764

#kernel #LinuxKernel

@kernellogger I was surprised to see a new driver in a later rc.

What have people been doing with link: ? Just using it as a private reply field?

@tripplehelix it's not a "new" driver, it's a revert of a revert (aka reapply), so it's a regression fix while the risk of regressions in other stuff is nearly zero in a case like this – so why wait.

@tripplehelix reg. the link: see the link in the first toot for details and/or search like this https://lore.kernel.org/all/?q=f%3Atorvalds%20link

@kernellogger And I feel like I still waste too much time finding the original submissions for commits that do not have Link:-tags...

@geert seems there are a lot of people that find them useful (me included[1]), but seems we somehow need to convince Linus about that.

[1] but they are not perfect, which is why I wonder these days if a change-id approach with a automatically added lore-link would be better (you'd (1) find all the submissions immediately, even if (2) the patch summary changed)

@kernellogger @geert I guess the root of the problem is that "Link:" is too vague to document its own purpose so it's being used for multiple things.

I don't think Linus would object to a new, more specific tag for submission links that he can easily ignore.

@andyprice @geert three years ago I proposed dedicated tags and he opposed them iirc. This was one of the early discussions, not sure if he shot them down later on the list or in in-person discussions on the summit.

https://lore.kernel.org/all/cover.1637566224.git.linux@leemhuis.info/

@kernellogger @geert That 6.17-rc5 was third complain ~last two weeks about Link tag, so I dropped it from my scripts. I see the rationale that automatically added Link which points to latest patch version, not even to the one with some sort of review happening, is just convenience instead of copy-paste of subject to lore.kernel.org. Useful to me but not worth dying for and I actually understand preference of having really useful Link or no Link at all.

@krzk @kernellogger @geert use patch.msgid.link domain for provenance links.

@krzk @kernellogger @geert I have something for this: https://git.kernel.org/pub/scm/linux/kernel/git/vegard/linux.git/about/

It's basically cross-referencing lore and git (and a bunch of other stuff like CVEs, stable, syzbot links, etc.) and adding the links as git notes (displayed after the changelog). There's obviously a delay between the data being available and it actually updating. I haven't been updating it very often but I would if there were actual users.

@krzk @kernellogger @geert Here's a recent example for a commit that didn't have a Link: tag: https://git.kernel.org/vegard/c/dcb23e1878013

@monsieuricon @geert @kernellogger So basically:

git config --global b4.linkmask 'https://patch.msgid.link/%s'

@monsieuricon @kernellogger @krzk Who owns the msgid.link domain?

@geert @monsieuricon @kernellogger
https://b4.docs.kernel.org/en/latest/config.html
> can also use https://msgid.link/%s, which is an alias for lore.kernel.org.
So I would guess that should be same owner as for kernel.org. Otherwise b4 docs should not recommend it.

@geert @kernellogger @monsieuricon Very secretive:
" Name: On behalf of msgid.link OWNER
Organization: c/o whoisproxy.com "

@geert @kernellogger @krzk LF owns msgid.link

@krzk @kernellogger @monsieuricon .git/hooks/applypatch-msg updated.
Any plans to update Documentation/maintainer/configure-git.rst? It still has the superfluous "/r", too.
Oh...
https://lore.kernel.org/all/87segwyc3p.fsf@trenco.lwn.net

@geert @kernellogger @monsieuricon So I guess that's the answer to question if patch.msgid.link domain solves Linus' issue:
https://lore.kernel.org/all/497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz/

@monsieuricon @kernellogger @krzk @geert are we allowed to do that or will that get us yelled at?

@brauner @monsieuricon @kernellogger @geert Please check the link to doc patch from @geert - different domain does not solve dislike for automated Link:, as it seems.

@krzk @kernellogger @geert how do you define 'really useful' exactly?

I mean it's useful to get to the discussion of the latest revision of a patch, but what exactly pushes it into 'really' useful?

This whole thing is utterly bizarre.

@krzk @kernellogger @monsieuricon @geert
If the intent of including an automatically generated reference is for provenance and not background information and discussion references for the reviewer, would labeling it something besides Link: be acceptable? E.g. Provenance: or Linus-ignore-this:, and then Link: references should be pointers to the kinds of references that are useful for a reviewer or history spelunker trying to understand the why of the commit.