Re: [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process

On 7/17/26 18:17, Linus Torvalds wrote:
> On Fri, 17 Jul 2026 at 18:09, Laurent Pinchart
> <[email protected]> wrote:
>>
>>> And then Y doesn't get done, and maybe X doesn't get done _either_,
>>> just because of some unrelated issue was pointed out as part of the
>>> discussion.
>>
>> It has caused and still causes friction, but I wouldn't dismiss it
>> entirely. I have seen multiple maintainers, including myself, ask for
>> yak shaving in ways that worked reasonably well. The key was to judge
>> how much yak shaving is reasonable (and the answer is invariably less
>> than a maintainer would wish for), and not making it mandatory.
> 
> I agree that it sometimes works, and can even work well - a maintainer
> suggestion of "if you did this, that will clean things up" can even be
> a welcome thing - particularly when it is relevant to the original
> series and not just an incidental tangential thing.
> 
> But we've also had maintainers that tried to get unrelated work done
> by making it a requirement for the subsystem, and pushed it way too
> hard, and it only resulted in problems.
> 
> So it *can* work, but as you say, it requires social skills and the
> ability to judge whether it's appropriate.
> 
> And I think that when there is AI review, people are less likely to
> see it as a positive thing when the AI then points out pre-existing
> problems.
> 

I agree, and I have seen that pattern.

I do not expect patch authors to fix pre-existing issues in my
scope of responsibility, though I appreciate it if they do it.
I actually asked Roman if it would be possible to add a per-subsystem
prompt to Sashiko's reply. That would let me inform authors that
I do not mandate fixing such issues.

Maybe that could be extended to a per-subsystem flag such as "report
pre-existing issues in your reply" to let maintainers decide
if they want Sashiko's reply to include them or not. For my part,
I rather have them included and deal with the possibly negative
reaction than not reporting them in the first place, for several
reasons:

- Most patch authors do care about the status of the driver(s) they are
   working on, and are absolutely interested in fixing pre-existing
   issues.

- As a maintainer, I _absolutely_ want to know about pre-existing
   issues, even if they are not (or not immediately) getting fixed.
   In my scope of responsibility, almost all of them are real,
   embarrassing as it may be. If I don't know about them they are never
   going to get fixed.

- Recently it happens a lot that I get patches fixing some minor
   issue in a 20+ years old driver (such as replacing strncpy()).
   That often results in Sashiko reporting several _real_ problems
   in the affected drivers. I can (and do) use that reply to ask
   patch authors to fix real problems instead of or in addition to
   cosmetic ones.

Guenter