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

[Arnaldo Carvalho de Melo <acme@kernel.org>]

On Thu, Oct 09, 2025 at 12:37:50PM +0300, Laurent Pinchart wrote:
> On Wed, Oct 08, 2025 at 04:39:17PM -0300, Arnaldo Carvalho de Melo wrote:
> > On Wed, Oct 08, 2025 at 10:33:49PM +0300, Laurent Pinchart wrote:
> > > On Wed, Oct 08, 2025 at 04:28:14PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > On Wed, Oct 08, 2025 at 09:08:33PM +0200, Andrew Lunn wrote:
> > > > > But ideally, we want the developers to use these tools and fix
> > > > > the issues before they post code for review.

> > > > Sure, as before, people should try to follow the best practices before
> > > > sending pull requests, its in the best interest of everybody.

> > > > But if they do so, and I guess most will, there will be more patches
> > > > flowing upstream, thus Chris effort, I think, right?

> > > I'd argue there will be less patches flowing upstream, lots of v1 (and
> > > sometimes subsequent versions) where maintainers point obvious mistakes
> > > will be avoided. The new v1 that would end up on the list will take more
> > > time to review than the old v1, but that's just because the new v1 will
> > > be the old v2.
> > 
> > Hopefully, but then all that time the contributors had to spend on
> > writing multiple versions for the same patch could be used to send tons
> > of good v1 patches, leading to more features, or dealing with lots of tech
> > debt most people have. :-)

> One can always dream :-)

:-)

> If you think of a series that goes from v1 to v10 today, we will just
> not see v1 on the list and v2 to v10 will be renamed v1 to v9, but the
> submitter will still make a v1, run it through tests, and fix issues
> before submitting. This will likely take less time than waiting for a
> review on v1, but will still take development time.

Right, using AI to do pre-review should be encouraged, some people will
not want to use some, while find some more acceptable, some will not use
any and will ask a friend, more effort before sending patches is what
maintainers need.
 
> > > To make this happen, though, maintainers will need to be reasonably
> > > confident that obvious mistakes will have already been fixed.

> > I think maintainers can't take anything for sure, even when dealing with
> > contributors that posted tons of patches before :-/

> > And as you said, we can't count on contributors running existing tests,
> > or using things like linters, checkpatch, you name it, let alone AI
> > assistants.

> A big difference is that we can complain about submitters not running
> checkpatch, but we can't insist they run proprietary tools.

I agree that we shouldn't make it a requirement that a proprietary tool
be used to make development dependent on it, not even require that
something that doesn't run locally, I'd say.

But this is no bitkeeper, I think, or shouldn't be, i.e. if you
completely stop thinking and trust just LLMs to code and review for
you...

Supposedly we can at any time stop using it and go back to our old ways,
no? :-)

Oh, it may be a bitkeeper, so convenient, who would want to use just
patches....

- Arnaldo