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

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

(Changing the subject and aiming this at workflows.)

On Fri, Sep 05, 2025 at 11:06:01AM -0700, Linus Torvalds wrote:
> On Fri, 5 Sept 2025 at 10:45, Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> >
> > Do you just want this to become a no-op, or will it be better if it's used
> > only with the patch.msgid.link domain namespace to clearly indicate that it's
> > just a provenance link?
> 
> So I wish it at least had some way to discourage the normal mindless
> use - and in a perfect world that there was some more useful model for
> adding links automatically.
> 
> For example, I feel like for the cover letter of a multi-commit
> series, the link to the patch series submission is potentially more
> useful - and likely much less annoying - because it would go into the
> merge message, not individual commits.

We do support this usage using `b4 shazam -M` -- it's the functional
equivalent of applying a pull request and will use the cover letter contents
as the initial source of the merge commit message. I do encourage people to
use this more than just a linear `git am` for series, for a number of reasons:

- this clearly delineates the start and end of the series
- this incorporates the contents cover letter that can give more info about
  the series than just individual commits *without* the need to hit the lore
  archive
- this lets maintainers record any additional thoughts they may have in the
  merge commit, alongside with the original cover letter

Obviously, we don't want to use the cover letter as-is, which is why b4 will
open the configured editor to let the maintainer pulling in the series make
any changes to the cover letter before it becomes the merge commit.

Having the provenance link in the cover letter as opposed to individual
commits makes perfect sense in this case, especially because it is now very
obvious where the series starts and ends.

This does create a lot more non-linear history, though. Judging from some of
my discussions on the fediverse, some maintainers are not sure if that's okay
with you. If that's actually your preferred way of seeing series being
handled, then I'll work on updating maintainer docs to indicate that this is
the workflow to follow.

Question -- what would be the preferred approach for single-patch submissions?
I expect having a merge commit for those would be more annoying?

> Anyway, the "discourage mindless use" might be as simple as a big
> warning message that the link may be just adding annoying overhead.
> 
> In contrast, a "perfect" model might be to actually have some kind of
> automation of "unless there was actual discussion about it".
> 
> But I feel such a model might be much too complicated, unless somebody
> *wants* to explore using AI because their job description says "Look
> for actual useful AI uses". In today's tech world, I assume such job
> descriptions do exist. Sigh.

So, I did work on this for a while before running out of credits, and there
were the following stumbling blocks:

- consuming large threads is expensive; a thread of 20 patches and a bunch of
  follow-up discussions costs $1 of API credits just to process. I realize
  it's peanuts for a lot of full-time maintainers who have corporate API
  contracts, but it's an important consideration
- the LLMs did get confused about who said what when consuming long threads,
  at least with the models at the time. Maybe more modern models are better at
  this than those I tried a year ago. Misattributing things can be *really*
  bad in the context of decision making, so I found this the most troubling
  aspect of "have AI analyze this series and tell me if everyone important is
  okay with it."
- the models I used were proprietary (ChatGPT, Claude, Gemini), because I
  didn't have access to a good enough system to run ollama with a large enough
  context window to analyze long email threads. Even ollama is questionably
  "open source" -- but don't need to get into that aspect of it in this
  thread.

However, I feel that LLMs can be generally useful here, when handled with
care and with a good understanding that they do and will get things wrong.

> For example, since 'b4' ends up looking through the downstream thread
> of a patch anyway in order to add acked-by lines etc, I do think that
> in theory there could be some "there was lively discussion about this
> particular patch, so a link is actually worth it" heuristic.
> 
> In theory.

Yeah, in practice we can't tell a simple "good job, here's a reviewed-by" from
a "lively discussion," especially if the lively discussion was about something
else that had nothing to do with the contents of the series (e.g. as this
thread). The clever-er we try to be with b4, the quicker we run into corner
cases where our cleverness is actually doing the wrong thing.

So, I'm generally on the side of "dumb but predictably so."

-K