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

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Thu, Jul 23, 2026 at 03:59:37PM +0100, 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.

Yes, we should have a happy medium point here. And let's use the tool
to save both maintainers's and developer's time.

I agree with Guenter approach here and in a matter of fact, I had just used
a few minutes ago. I had to review a series where I noticed Sashiko had a
couple of true finds. So, I just asked the developer to look to that report
and fix that before I waste my time with reviews that the tool could already
spot.

But I was already aware-of and okay-with this entire code design idea and
approach and this review would be more about the correctness.

And this reminds me about the old but gold Sage's post on patch review:
https://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/

"""
1. Is the idea behind the contribution sound?
2. Is the contribution architected correctly?
3. Is the contribution polished?
"""