(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 > <[email protected]> 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
