Re: [MAINTAINERS SUMMIT] [4/4] Discuss how to better prevent backports of commits that turn out to cause regressions

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, 15 Jun 2024 at 20:28, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> I prefer that "Link:" goes back to a discussion, but I would like a
> separate tag for where the patch came from. What would you suggest?

I really don't see the advantage of a separate tag name, and I see
actual and immediate disadvantages.

The thing is, I want commit messages to be links, because I do *NOT*
want people to be in the situation where they ask themselves "how do I
look this ref up"?

Yes, a message-ID is often easy to just plug into lore. But as you -
and others - already noted, making it a link means that you don't have
to "plug it into X" at all, and it just works in many different
contexts.

And lore does not index all email.

Which gets me to the other reason I want a link, and why I want to
*name* it "Link".

Because when I say "link", I very much mean exactly that.

It's not an URI, the key part really is that "L" for Link. It needs to
actively point to something on the internet.  It's not some random
uniform resource identifier, it's an honest-to-goodness "this is the
actual link to the information"..

So I don't want things that point to something on your company intranet.

Nor do I want identifiers to something in your mailbox.

It's *not* supposed to be a message ID, exactly because to be
meaningful, it has to point to *public* data, and it has to be a real
link, and the tag name should make that clear.

And that's why the name "Link:" is important too.

Because part of this is very much a social contract: we are working on
open source, and the keyword here is open. Using a "Link" name kind of
mentally enforces that social contract.

Yes, yes, others use git for their own nefarious reasons, and if you
are working inside a company on some closed source thing, by *all*
means have tags like "Closes-bug: 54321".

But that's not what the kernel is.

We have years of people wanting to add their own meaningless "bug ID"
crap. Or other internal useless markers.

And that is *explicitly* what I don't want, and why I want it to be
completely obvious and very very explicit that the only thing that is
valid is a real public link.

And finally - if you applied the patch by just following a message ID
with basically "b4" from lore, I think the source link is almost
entirely worthless.

Here's the thing: if you applied it unchanged from lore, you already
have the email address and a date in the commit.

Are you seriously saying that you can't find it based on that?

Now, if you *base* your commit it on somebody elses work on the lists,
you should most definitely say that, and say something like

   Based on patch submission by Xyz at [1]

   Link: https://lore.kernel.org/...../ [1]

and that's _wonderful_.

But if you just did "b4 am" and applied a patch, what's the advantage
of including information that adds no real value?

So a pure source link I still find to be of *very* questionable value,
compared to things that have actual obvious real value:

 - bug reports

 - background discussion

 - pointers to earlier versions that didn't get committed

so yes, I find it almost offensive when I have to debug a problem, and
I find a Link: that I hope explains things, and all it just shows is
the SAME DAMN INFORMATION that was in the commit already, and that I
could trivially have found by just searching lore for the author and
date.

At that point, "Link:" is just wasting my time.

And I'm not making up that "search lore for author and date range"
thing. That's EXACTLY what I do. Not to find the original submission,
but to find the discussion about things. Sometimes years prior.

A few days ago, I literally did exactly that to find some background
for a commit from 2011.

Btw, as a realted issue, is why I also despise the syzkaller
convention of hiding magic noise in other tags too, like

    Reported-by: syzbot+6a038377f0a594d7d44e@syzkaller.appspotmail.com

because that's exactly the kind of "ok, how the f*%^ do I look this
up" kind of noise.

And yes, we have exactly that kind of noise in the kernel logs, and
it's wrong. I didn't make that one up.

Now, often - but sadly not at all always - we also end up having an
actual link, eg

    Reported-by: syzbot+9bbe2de1bc9d470eb5fe@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=9bbe2de1bc9d470eb5fe

so that actually says "Oh, look, _that_ is how I look up the noise".
But I'd much rather just see "Link" over "Closes", and generally to
the actual report on lore, if there was any discussion about it.
Because from a kernel standpoint, if something causes problems, the
fact that it _closed_ a bug report is not what is important, is it?
No, the reason you want to look at that link is because the fix caused
problems, and you want the background on it and the original report.

So again, "Closes" is wrong. Why? Same damn reason: make it really
really obvious that what we want is a *LINK*. Not a "syzbot ID".
That's wrong for exactly the same reason "Message-ID:" is wrong.

TL;DR:

 - if you add a "Link:" there should be some *value* to the link, over
and above "I can find this on lore by just searching for it".

- there are seldom any real reasons to use anything but "Link:", and
we have absolutely years of people arguing for their own internal
bug-IDs that argue *against* making it very very clear that it should
be a valid link

Thus endeth my rant.

             Linus