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