RE: [MAINTAINERS / KERNEL SUMMIT] AI patch review tools

["Bird, Tim" <Tim.Bird@sony.com>]

> -----Original Message-----
> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> On Thu, Oct 09, 2025 at 04: 51: 39PM +0200, Andrew Lunn wrote: > On Thu, Oct 09, 2025 at 10: 30: 19AM -0400, Steven Rostedt wrote: > > On
> Thu, 9 Oct 2025 12: 14: 05 +0300 Laurent Pinchart wrote: > > > > > Forcing contributors
> On Thu, Oct 09, 2025 at 04:51:39PM +0200, Andrew Lunn wrote:
> > On Thu, Oct 09, 2025 at 10:30:19AM -0400, Steven Rostedt wrote:
> > > On Thu, 9 Oct 2025 12:14:05 +0300 Laurent Pinchart wrote:
> > >
...
> The Linux media subsystem CI does pretty much the same. It's been
> working quite OK, although dealing with false positives is not easy.
> checkpatch.pl for instance returns lots of false positives (or rather
> real violations of the coding style that are fine to ignore), and
> contributors get an automated e-mail to tell them to fix and resubmit.

False positivies is one of the issues we should address.  See below for
some ideas to address them.

In my understanding, if developers are not running
checkpatch.pl before sending things in, it creates some churn.  I think
our current way of handling this is just to automate handling the churn
instead of actually addressing the problem at the time of development.
Ostensibly, people are not ignoring errors from gcc before sending patches in.
Maybe if some of the checks that checkpatch.pl does (the non-false-positive ones)
were integrated into the build, it would result in those items having immediate
visibility to the developer, at the time of code creation.  And they'd get fixed
before the patch was ever created.

One issue with checkpatch.pl is that some items it complains about are low
importance or even ignorable, depending on the taste of the maintainer.
This means different maintainers will have different views of what constitutes
a false positive.  This makes it difficult to be strict about running the tool or
addressing the issues it raises.  Also, it is run too late in development, IMHO
(see above).

I have ideas to address the false positive rate, based on features that checkpatch.pl
already has, as well as ideas for handling some of the concerns that running
checkpatch.pl (or an equivalent) at build time would raise.  Some of these might
apply to AI review as well.  Let me know if you want me to elaborate, or if we
should just discuss in Tokyo.
 -- Tim