From: Steven Rostedt <rostedt@goodmis.org>
To: Roman Gushchin <roman.gushchin@linux.dev>
Cc: ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process
Date: Wed, 15 Jul 2026 20:03:34 -0400 [thread overview]
Message-ID: <20260715200334.70390a27@robin> (raw)
In-Reply-To: <7ia4qzl45h20.fsf@castle.c.googlers.com>
On Wed, 15 Jul 2026 16:55:03 +0000
Roman Gushchin <roman.gushchin@linux.dev> 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
next prev parent reply other threads:[~2026-07-16 0:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 16:55 [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process Roman Gushchin
2026-07-15 17:51 ` Miguel Ojeda
2026-07-15 21:37 ` Roman Gushchin
2026-07-15 17:56 ` Mauro Carvalho Chehab
2026-07-15 18:57 ` Jason Gunthorpe
2026-07-15 21:21 ` Roman Gushchin
2026-07-15 19:45 ` Dmitry Torokhov
2026-07-16 0:03 ` Steven Rostedt [this message]
2026-07-16 0:30 ` SJ Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260715200334.70390a27@robin \
--to=rostedt@goodmis.org \
--cc=ksummit@lists.linux.dev \
--cc=roman.gushchin@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox