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

On Wed, 15 Jul 2026 16:55:03 +0000
Roman Gushchin <[email protected]> wrote:

> Sashiko and AI code reviews in general have gained a lot of traction in
> 
> Some specific topics I propose we discuss:
> * Review of LTS patches and kernel releases.

Honestly, I think those that use LTS should get together and support
developers that will look at the reviews of LTS and push to get the
fixes for them. I keep hearing that LTS is used more than mainline and
upstream doesn't put as much priority in what goes into LTS (and stable
in general) as it does for mainline. Perhaps those that depend on LTS
and stable should be the ones doing the work.

> 
> * How to maintain the long-term stability of Sashiko?
> Several kernel engineers and maintainers have rightfully expressed
> concerns about relying on infrastructure provided by a single company
> without clear formal guarantees. It would be great to discuss what a
> more sustainable model could realistically look like and how we might
> get there.

As I believe Jason already mentioned, it would be great if we could
possibly get kernel specific model information that can be shared.
Possibly even with an open source model so those that want to buy a
NVidia Spark or something similar could run their own reviews ;-)

> 
> * Handling of pre-existing bugs.

I like the pre-existing bugs. But I do agree it shouldn't be sent to
the author of a patch. It should either be a separate review or email
that says "Oh I found these pre-existing bugs around the code that was
modified". I want to know what pre-existing bugs are in the code I
maintain, and I would love to make sure that it's public so that
someone else might want to do the fix ;-)

> 
> * Prompt development and testing.

No comment.

> 
> * Interactive mode.

Yes, this is something I would love to have. There's some unique ways
the code works that Sashiko could use to get better.

-- Steve