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

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Sat, Jun 15, 2024 at 09:59:40PM GMT, Linus Torvalds wrote:
> 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.

I have to continue to disagree here. I need something *reliable* for
automation to work. If automation fails even 10% of the time, it generates
confusion. I have lots of reports from people where b4 was able to match 9 out
of 10 commits because the author changed something minor in patch 8/10, and so
the patch-id no longer matched. As a result, committers follow up with "why
didn't you apply 8/10" and the maintainers then have to reply with "oh, I did,
but b4 got confused."

Message-IDs are the perfect solution to this problem -- they are a reliable
mechanism to match a commit to the patch where it came from. I don't care if
they are part of the Link: trailer, but I do care to know *which one* of the
Link: trailers point at the original submission. If there are multiple Link:
trailers pointing at lore, one for the patch submission, and another for a
series dependency, discussion, or an alternative implementation of the same
thing, then I no longer have a reliable course of action.

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

There are situations where this is unreliable for automation:

- the patch has the "From:" header inside the body that is different from the
  "From:" message header (this is why this would fail most commonly)
- the patch has a "Date:" or "Subject:" headers inside the body that override
  the "Date:" or "Subject:" headers in the message
- the author sends the series to a test list
- the author sends the series for a pre-review to the newbies list ("hey, can
  someone quickly confirm that this looks good?")
- the author sends the series to the wrong list, and then corrects themselves
  and sends it to the correct list
- the author sends the same patch as part of multiple series, in the hopes
  that one of them gets through

All of these cases would cause automation to fail.

I understand the reasons why everyone hates having the "Message-ID:" trailer,
and this is fine. Can I counter-propose that we have a unique URL for links
specifically going to patch submissions from which the commits were made? I've
been already recommending using the "msgid.link" domain, but I'll go a bit
further and put forward the recommendation that:

- commits MAY have Link: trailers indicating the exact origin of the patch. To
  distinguish these links from other Link: trailers that may lead to relevant
  online discussions, they should either use the "patch.msgid.link" domain, or 
  indicate the nature of the link using the hash-notation. Examples:

  - Link: https://patch.msgid.link/message@id-here
  - Link: https://lore.kernel.org/message@id-here # patch

This would satisfy both the need for automation to have a reliable way to find
the origin of the commit, and clearly indicate the nature of the link for
humans doing commit spelunking.

-K