From: SJ Park <sj@kernel.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: SJ Park <sj@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Jason Gunthorpe <jgg@nvidia.com>,
ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process
Date: Sat, 18 Jul 2026 09:15:41 -0700 [thread overview]
Message-ID: <20260718161542.82772-1-sj@kernel.org> (raw)
In-Reply-To: <efdce5c5-13a1-4dec-9823-bb2a37084538@roeck-us.net>
On Sat, 18 Jul 2026 07:14:02 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
[...]
> I do not expect patch authors to fix pre-existing issues in my
> scope of responsibility, though I appreciate it if they do it.
> I actually asked Roman if it would be possible to add a per-subsystem
> prompt to Sashiko's reply. That would let me inform authors that
> I do not mandate fixing such issues.
I agree such customized review could make it more clear and helpful. But I
also concern if it could make Sashiko reply unnecessarily verbose. Especially
when a patch is toucing multiple subsystems.
In my humble opinion, it is a common sense not asking patch contributors to fix
pre-exising issues. Of course it depends, but that's what requires and
deserves additional discussions in my opinion.
If subsystem-specific rules are really required, maybe we can use subsystem
maintainer profile document? For example, DAMON maintainer profile has a
section [1] for AI review. And I now realize the document is quite outdated,
though.
[1] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#ai-review
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-07-18 16:15 UTC|newest]
Thread overview: 22+ 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-17 6:43 ` Ben Copeland
2026-07-16 15:32 ` Sasha Levin
2026-07-15 17:56 ` Mauro Carvalho Chehab
2026-07-15 18:57 ` Jason Gunthorpe
2026-07-15 21:21 ` Roman Gushchin
2026-07-16 22:26 ` Mauro Carvalho Chehab
2026-07-17 23:17 ` Linus Torvalds
2026-07-18 0:01 ` Mark Brown
2026-07-18 1:09 ` Laurent Pinchart
2026-07-18 1:17 ` Linus Torvalds
2026-07-18 13:38 ` Arnaldo Melo
2026-07-18 14:14 ` Guenter Roeck
2026-07-18 16:15 ` SJ Park [this message]
2026-07-18 16:13 ` Jason Gunthorpe
2026-07-15 19:45 ` Dmitry Torokhov
2026-07-16 0:03 ` Steven Rostedt
2026-07-16 0:30 ` SJ Park
2026-07-17 21:05 ` Krzysztof Kozlowski
2026-07-17 21:14 ` Roman Gushchin
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=20260718161542.82772-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=jgg@nvidia.com \
--cc=ksummit@lists.linux.dev \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux@roeck-us.net \
--cc=roman.gushchin@linux.dev \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.