From: Lorenzo Stoakes <ljs@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Christian Brauner <brauner@kernel.org>,
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
Subject: Re: [PATCH RFC] coding-assistants: simplify attribution
Date: Thu, 2 Jul 2026 11:04:35 +0100 [thread overview]
Message-ID: <akYz2aMIco1fbD-t@lucifer> (raw)
In-Reply-To: <1f29f48d-b9ff-4de2-a392-dc05781728be@kernel.org>
(thanks for the cc-!)
On Thu, Jul 02, 2026 at 09:46:37AM +0200, David Hildenbrand (Arm) wrote:
> 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:
A single comment is complexity?
> >
> > 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.
Yup I couldn't disagree more with Christian here, the whole thing feels like
trying to 'wish away' the AI issue, and now punting off to subsystem
maintainers...
Subsystems impact each other. Right now I'm writing a series that changes driver
code so we can enforce some sanity in mm APIs.
I've had to interact with fs code quite a bit that uses mm logic.
It's all interconnected, and one subsystem let's say going with 'let it all in'
say, impacts another.
Yes some people lie about it, but having the guidelines only STRENGTHENS our
position on that, and I've seen that in practice.
So yeah, sorry, I think it's beyond silly to push back on requesting somebody
disclose how much of a patch/series was AI generated.
And [0] already essentially says people NEED to do this now. But that doc has
been rather downplayed unfortunately I think.
>
> >
> > 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.
Again, asking LLM submitters to write a single comment is 'beaurocracy'?
>
> 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 disagree, I think it's important to have it standardised and simple.
If we make things vague, people won't do it. And reading through a cover letter
in its AI slop entirety (and boy does it generate a LOT of text) to find the
mention or not (and hey what if it's not clear?) is just objectively worse.
>
> 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.
For me it's about empowering maintainers to push back.
>
> >
> > 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.
Not sure about that, if it turns out AI-generated patches are causing 95% more
bugs say that's pretty useful information no?
Or if you find that a patch somebody sent from another subsystem that has a
lassez faire approach to AI slop completely breaks you in some subtle way, isn't
it easier to push for a revert if you see it's LLM-generated?
And is it really that egregious to include a tag? You can ignore it if you don't
care.
>
> --
> Cheers,
>
> David
Thanks, Lorenzo
[0]:https://docs.kernel.org/process/generated-content.html
next prev parent reply other threads:[~2026-07-02 10:04 UTC|newest]
Thread overview: 29+ 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-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)
2026-07-02 8:10 ` Laurent Pinchart
2026-07-02 8:16 ` David Hildenbrand (Arm)
2026-07-02 10:04 ` Lorenzo Stoakes [this message]
2026-07-02 8:08 ` Laurent Pinchart
2026-07-02 8:28 ` Christian Brauner
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 10:34 ` Krzysztof Kozlowski
2026-07-02 10:27 ` Krzysztof Kozlowski
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=akYz2aMIco1fbD-t@lucifer \
--to=ljs@kernel.org \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.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