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

Guenter Roeck <[email protected]> Thu, 23 Jul 2026 10:27:07 -0700
Newsgroups dev.linux.lists.ksummit
Message-ID <[email protected]>
On 7/23/26 07:59, Mark Brown wrote:
> On Thu, Jul 23, 2026 at 07:34:58AM -0700, Guenter Roeck wrote:
> 
>> Last night I got a patch submission of a ~350 LOC driver. Sashiko reported
>> 9 issues with it. No, it is not ok for the author to ignore Sashiko's feedback,
>> and I am not even going to look at the code myself until the reported issues
>> are either fixed or the author explains why they don't apply.
> 
>> It is fine (I would say acceptable) to ignore _pre-existing_ issues reported
>> by Sashiko, but I do expect patch authors to address new issues, or to explain
>> why they are false positives or don't apply.
> 
>> If you want to give patch authors the option to ignore Sashiko's feedback
>> entirely, fine with me, but please do it on a per-subsystem basis.
> 
> OTOH I had a submitter send 15 versions of what should have been a
> relatively simple quirk over the weekend iterating with Sashiko, then
> the initial human review was "this seems like the wrong approach".  It
> feels like there's some happy medium here.

That is a different problem, though. Yes, I sometimes do get several
patch revisions in a single day. Sashiko tries to address that by
optionally delaying its response for a per-subsystem configurable period
of time, but that doesn't solve the real problem (which is that patch
authors sometimes send new revisions too quickly).

Either case, I think your example is rare enough that I'd rather deal
with the 15 revisions and not have to re-identify all the problems
that Sashiko _did_ find.

Guenter