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

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

> -----Original Message-----
> From: James Bottomley <James.Bottomley@HansenPartnership.com>
> 
> On Fri, 2025-10-10 at 10: 54 +0300, Laurent Pinchart wrote: > On Thu, Oct 09, 2025 at 06: 03: 45AM -0400, Chris Mason wrote: [. . . ] > I'm not
> that concerned about being locked to a specific vendor, but > more about being locked to a proprietory
> On Fri, 2025-10-10 at 10:54 +0300, Laurent Pinchart wrote:
> > On Thu, Oct 09, 2025 at 06:03:45AM -0400, Chris Mason wrote:
> [...]
[...]
> > If we were to push the burden of running LLM-based review to
> > contributors this wouldn't affect us that much, but if we run it on
> > the maintainers' side (be it on the server side with bots that get
> > patches from mailing lists, CI systems that feed from patchwork, or
> > on the client side) the risk of vendor lock-in is higher.
> 
> Pushing the burden on to contributors always causes more friction than
> building it into the CI.
This is true, but unfortunately this doesn't do anything to help contributors
perform this step themselves.  It actually, IMO, disincentives this from happening.

>  Plus if there's a cost involved you're making
> contribution pay for play which really doesn't work out well.
> 
> >  Maybe proprietary technology lock-in would be a better description
> > as this isn't about a single vendor.
> 
> Well, firstly we've had this before: us with bitkeeper and most
> recently Kubernetes with Slack and everyone has survived. But secondly
> the far more likely scenario is that the AI stock bubble bursts and the
> investment dries up changing the way AI is done (definitely killing the
> who can by powerstations and huge hardware installations model of
> today) and who the players are (probably the point at which open source
> becomes more prevalent).
> 
> However, regardless of what happens in future, it will be way easier to
> cope with if we've got AI in the CI rather than trying to push it into
> contributor tooling.

I think if you put AI review into contributor tooling (like B4, or as a target in
the kernel build), it still allows for central control over the mechanisms and
policies for AI review, to be able to adapt to changing AI considerations.
It should also make integration into CI easier.

But it lowers the barriers (e.g. AI learning curve) for contributors to more easily
do it themselves, and migrate to a model where these bugs are caught earlier
in the development cycle, before the patches are created,  and ultimately reduce
the "submit-feedback-fix" churn I mention elsewhere.

We use a "build-feedback-fix" cycle for compilation errors.  It would be nice if we could
move to a similar model (instead of "submit-feedback-fix" cycle) for coding style
and semantic errors as well.

Regards,
  -- Tim