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

2026=E5=B9=B47=E6=9C=8824=E6=97=A5(=E9=87=91) 2:46 Guenter Roeck <linux@roe=
ck-us.net>:
>
> 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 repo=
rted
> >> 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 re=
ported
> >> 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 feedb=
ack
> >> 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.

One thing that I find tedious when reviewing further revisions of a
patch (series), and that would be exacerbated by having even more
revisions, is ensuring that all the comments from the previous
revision(s) have been addressed. Is this something that Sashiko, or
some other review tools (possibly non-AI) could help with?

(For a comparison, the Android/Chromium Gerrit, which is somehow so
hated by the kernel developers outside of Google, allows me to easily
see the difference between any given revisions, lined up with comments
from those revisions, making it really easy to confirm the necessary
changes are there.)

Best,
Tomasz