From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>, Jens Axboe <axboe@kernel.dk>,
Jeff Layton <jlayton@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
workflows@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
"Lorenzo Stoakes (Oracle)" <ljs@kernel.org>
Subject: Re: [PATCH RFC] coding-assistants: simplify attribution
Date: Thu, 2 Jul 2026 09:46:37 +0200 [thread overview]
Message-ID: <1f29f48d-b9ff-4de2-a392-dc05781728be@kernel.org> (raw)
In-Reply-To: <20260702-seekrank-stilrichtung-mitentscheiden-69a64ee097ec@brauner>
On 7/2/26 09:27, Christian Brauner wrote:
>> What would be much more relevant to know is to which degree LLMs were used.
>>
>> Assisted-by: LLM # translate commit message
>> Assisted-by: LLM # generate some test cases
>> Assisted-by: LLM # cleanup logic
>> Assisted-by: LLM # everything and I have no clue what any in here does
>
> I think we should just drop any attribution as a general kernel-wide
> rule and let subsystems require them as needed. Then you can have all
> the complexity in mm for this that you think is needed for your
> workflow to function. This is precisely what the subsystem profiles are
> for. So maybe just add:
>
> Documentation/process/maintainer-mm.rst
>
> alongside
>
> Documentation/process/maintainer-{tip,netdev,x86}.rst
>
> and lay down the rules that you require for LLM based submissions in
> whatever detail you need.
I'm not really sure if having (more?) subsystem-specific tags is the way to go.
(below)
So either we find a very simple, kernel-wide rule for such tags, or we drop them
entirely.
>
> I don't see how this additional commentary you want would ever be
> enforced consistently across the kernel or who would even enforce it. I
> don't need more beaurocracy to chase after people in my subsystems tbh.
That's certainly a good thing to discuss. (below)
>
> The other thing is that I think this Assisted-by annotation is just
> noise in the changelog. If you want to know in detail what an LLM was
> used for when generating the patch it's mostly a signal for how
> "intense" of a review this will get afaict (already questionable imho
> but sure that's just something to disagree on).
I'd be happy to just have such information in the cover letter. Without any
tags. Having subsystem-specific rules on the disclosure on that might be more
reasonable.
I agree on the "enforce" aspect. It's impossible, but it's still easy to catch
people using AI irresponsibly today ... and that's what we care about. Not
people that know what they are doing using AI responsibly.
>
> If the information is mostly useful during review then I still would
> question why it has to end up in our git logs. It's completely
> irrelevant information imho.
Fully agreed. In the tree it's irrelevant.
--
Cheers,
David
next prev parent reply other threads:[~2026-07-02 7:46 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 15:54 [PATCH RFC] coding-assistants: simplify attribution Christian Brauner
2026-07-01 16:08 ` Mark Brown
2026-07-02 7:10 ` Christian Brauner
2026-07-02 11:35 ` Mark Brown
2026-07-01 16:08 ` Jonathan Corbet
2026-07-01 16:12 ` David Hildenbrand (Arm)
2026-07-02 7:11 ` Christian Brauner
2026-07-02 9:51 ` David Disseldorp
2026-07-01 16:10 ` David Hildenbrand (Arm)
2026-07-02 7:27 ` Christian Brauner
2026-07-02 7:46 ` David Hildenbrand (Arm) [this message]
2026-07-02 8:10 ` Laurent Pinchart
2026-07-02 8:16 ` David Hildenbrand (Arm)
2026-07-02 10:04 ` Lorenzo Stoakes
2026-07-02 11:51 ` David Hildenbrand (Arm)
2026-07-02 12:49 ` Lorenzo Stoakes
2026-07-02 13:41 ` Jani Nikula
2026-07-02 13:48 ` Jeff Layton
2026-07-02 13:26 ` Christian Brauner
2026-07-02 13:35 ` Christoph Hellwig
2026-07-02 13:47 ` Laurent Pinchart
2026-07-02 13:57 ` Lorenzo Stoakes
2026-07-02 14:09 ` Christian Brauner
2026-07-02 8:08 ` Laurent Pinchart
2026-07-02 8:28 ` Christian Brauner
2026-07-02 13:48 ` Carlos Maiolino
2026-07-02 9:24 ` Lorenzo Stoakes
2026-07-01 18:35 ` Jeff Layton
2026-07-01 18:53 ` Jakub Kicinski
2026-07-02 7:29 ` Christian Brauner
2026-07-02 7:28 ` Christian Brauner
2026-07-02 8:12 ` Jori Koolstra
2026-07-02 8:44 ` Vlastimil Babka (SUSE)
2026-07-02 9:09 ` Jori Koolstra
2026-07-02 9:39 ` Lorenzo Stoakes
2026-07-02 9:37 ` Lorenzo Stoakes
2026-07-02 9:38 ` Laurent Pinchart
2026-07-02 9:44 ` Lorenzo Stoakes
2026-07-02 11:57 ` Brian Foster
2026-07-02 12:18 ` Lorenzo Stoakes
2026-07-02 13:07 ` Laurent Pinchart
2026-07-02 13:37 ` Lorenzo Stoakes
2026-07-02 13:47 ` Jori Koolstra
2026-07-02 13:09 ` Brian Foster
2026-07-02 13:25 ` Lorenzo Stoakes
2026-07-02 10:34 ` Krzysztof Kozlowski
2026-07-02 12:23 ` Lorenzo Stoakes
2026-07-02 12:39 ` Krzysztof Kozlowski
2026-07-02 12:53 ` Lorenzo Stoakes
2026-07-02 13:23 ` Laurent Pinchart
2026-07-02 10:27 ` Krzysztof Kozlowski
2026-07-02 11:27 ` Christoph Hellwig
2026-07-02 13:40 ` Carlos Maiolino
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=1f29f48d-b9ff-4de2-a392-dc05781728be@kernel.org \
--to=david@kernel.org \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=jlayton@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@kernel.org \
--cc=workflows@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox