From: lyude@redhat.com
To: Jori Koolstra <jkoolstra@xs4all.nl>, Kees Cook <kees@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>,
Sasha Levin <sashal@kernel.org>,
corbet@lwn.net, skhan@linuxfoundation.org,
federico.vaga@vaga.pv.it, apw@canonical.com, joe@perches.com,
workflows@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] docs: remove Assisted-by reference
Date: Mon, 19 Oct 2026 12:15:38 -0400 [thread overview]
Message-ID: <4a55a48948a1f01686b0471307b6fc2d52be7896.camel@redhat.com> (raw)
In-Reply-To: <as4gLo_6acb_zZu0@daedalus>
On Tue, 2026-10-13 at 14:28 +0200, Jori Koolstra wrote:
> On Tue, Oct 13, 2026 at 01:25:59AM -0700, Kees Cook wrote:
> > On Mon, Oct 12, 2026 at 10:56:59PM -0700, Randy Dunlap wrote:
> > > On 10/12/26 9:24 PM, Kees Cook wrote:
> > > > On Fri, Oct 09, 2026 at 04:31:37AM -0400, Sasha Levin wrote:
> > > > > The Maintainers Summit reached consensus to deprecate the Assisted-by
> > > > > tag. Remove the documentation requiring it.
> > > > >
> > > > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > >
> > > > Yup, it has become as redundant as specifying what editor I use. ;)
> > > >
> > > > Reviewed-by: Kees Cook <kees@kernel.org>
> > >
> > > and for those of us who don't know details about the discussion,
> > > how is it redundant?
> >
> > No, I mean I use an LLM constantly for almost all aspects of my
> > development work, in multiple dimensions, so if the old tag requirement
> > held, my email body template would just put "Assisted-by: LLM" in there
> > because at the very least, it drove the build and test stage. It was
> > redundant in the sense of "yeah, of course I used an LLM at some point
> > for this patch". ("This tag means nothing *from* me")
> >
> > > Do you assume that everyone now uses it (LLM), just as everyone
> > > uses an editor?
> >
> > I don't make that assumption, but I always held the position that the
> > tag was meaningless because it's the human wielding it that matters:
> > they either sent a good patch or a bad patch, and if it was mangled by
> > gmail or an LLM, it doesn't really matter. ("This tag means nothing *to*
> > me")
>
> I think the tag did have a genuine purpose for a while. Now we have just
> decided to implicitly attach it to every new submitter (because
> basically that is the case.) The point was that a patch that was
I know plenty of people who would love to contribute to the kernel who
haven't before, who do not want to be involved or use LLM tools in
their own development. Considering how much LLMs lower the bar for
people to be able to submit fixes, I think it's also worth pointing out
that just because you've sent a patch doesn't mean you're a contributor
who is going to actually come back or is actually interested in trying
to get a patch to the finish line. I've even ran into 'contributors'
who wouldn't even avoid using an LLM to respond to review feedback
which makes it nearly impossible for them to actually retain any of the
critique they've received on their work.
> obviously LLM generated could be rejected for not carrying the tag, and
> a patch that carried the tag could be asked to explain further (if they
> had not done so.) Or at least, that is how I felt and have understood
> Greg, for instance :)
>
> Essentially, the way I read it, is that Linus said we don't need this
> roundabout way because we can just reject effortless LLM generated
> patches outright. This is good and an improvement.
>
> What do you think about requiring people to explain how they used an LLM
> for code generation? I don't care if someone uses it for review, or
> brainstorming, or whatever, and I have never understood the tag to be
> required for that. But if the code is LLM generated, it would be nice to
> know for instance what prompts you used. We should have some way to not
> devolve into the maze that Jonathan Corbet has sketched, where no one
> really knows what's going on.
Prompts aren't deterministic, and this also expects that everyone is
using LLMs (most of the contributors I work with do not actually use
LLMs, and most of the ones who do stop short of actually generating
code outside of large tree-wide changes with it). There are also
already drivers in the kernel which have adopted their own no-LLM
policies.
I have wanted better tagging for a while, because I do agree Assisted-
by: isn't great, but just going "well you can reject slop :)" makes it
dramatically more difficult for me to tell the difference between a new
contributor who just doesn't know how to structure their patches
correctly, and one that just let their LLM take the wheel and barely
understands what they sent to me.
Something that would be dramatically better, and I really hope would be
considered over the nuclear option of just dropping this patch:
Co-authored-by: LLM
Reported-by: LLM
>
> Best,
> Jori.
>
> >
> > -Kees
> >
> > -- Kees Cook
prev parent reply other threads:[~2026-10-19 16:16 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 8:31 [PATCH] docs: remove Assisted-by references Sasha Levin
2026-10-09 9:38 ` Laurent Pinchart
2026-10-09 10:09 ` Sasha Levin
2026-10-09 10:05 ` Krzysztof Kozlowski
2026-10-09 10:24 ` Greg KH
2026-10-09 15:20 ` Jonathan Corbet
2026-10-11 1:04 ` Steven Rostedt
2026-10-12 15:42 ` Lorenzo Stoakes (ARM)
2026-10-13 11:19 ` Jori Koolstra
2026-10-13 12:38 ` Laurent Pinchart
2026-10-13 12:50 ` Jori Koolstra
2026-10-13 13:01 ` Laurent Pinchart
2026-10-13 13:24 ` Ricardo B. Marlière (SUSE)
2026-10-13 12:49 ` Lorenzo Stoakes (ARM)
2026-10-13 17:16 ` Laurent Pinchart
2026-10-13 12:31 ` Laurent Pinchart
2026-10-13 12:59 ` Lorenzo Stoakes (ARM)
2026-10-13 13:04 ` Krzysztof Kozlowski
2026-10-13 13:07 ` Lorenzo Stoakes (ARM)
2026-10-13 13:12 ` Laurent Pinchart
2026-10-13 13:29 ` Lorenzo Stoakes (ARM)
2026-10-13 13:37 ` Jori Koolstra
2026-10-13 14:52 ` Kees Cook
2026-10-13 14:54 ` Jori Koolstra
2026-10-13 14:58 ` Jori Koolstra
2026-10-13 17:12 ` Kees Cook
2026-10-13 17:42 ` Laurent Pinchart
2026-10-13 19:25 ` Kees Cook
2026-10-13 20:16 ` Laurent Pinchart
2026-10-13 20:45 ` Linus Torvalds
2026-10-14 13:56 ` Lorenzo Stoakes (ARM)
2026-10-16 14:19 ` Matthew Brost
2026-10-17 17:42 ` Troy Benjegerdes
2026-10-19 17:41 ` lyude
2026-10-14 18:47 ` Kees Cook
2026-10-15 23:14 ` Jeremy Dean Clifton
2026-10-13 15:02 ` Lorenzo Stoakes (ARM)
2026-10-13 16:58 ` Kees Cook
2026-10-13 17:32 ` Laurent Pinchart
2026-10-16 16:14 ` Lorenzo Stoakes (ARM)
2026-10-14 3:23 ` Theodore Tso
2026-10-14 11:23 ` Mark Brown
2026-10-14 13:08 ` Jori Koolstra
2026-10-14 13:42 ` Lorenzo Stoakes (ARM)
2026-10-14 14:15 ` Mark Brown
2026-10-19 22:44 ` Laurent Pinchart
2026-10-20 4:28 ` Theodore Tso
2026-10-19 16:32 ` lyude
2026-10-19 22:24 ` Laurent Pinchart
2026-10-19 16:26 ` lyude
2026-10-16 18:26 ` Ihor Solodrai
2026-10-19 16:21 ` lyude
2026-10-13 4:24 ` Kees Cook
2026-10-13 5:56 ` Randy Dunlap
2026-10-13 6:18 ` Greg KH
2026-10-13 8:25 ` Kees Cook
2026-10-13 12:28 ` [PATCH] docs: remove Assisted-by reference Jori Koolstra
2026-10-13 12:55 ` Laurent Pinchart
2026-10-13 13:03 ` Jori Koolstra
2026-10-13 13:10 ` Laurent Pinchart
2026-10-13 13:20 ` Jori Koolstra
2026-10-13 13:55 ` Laurent Pinchart
2026-10-19 16:50 ` lyude
2026-10-13 15:18 ` Mark Brown
2026-10-13 17:07 ` Laurent Pinchart
2026-10-13 20:01 ` Shuah Khan
2026-10-19 16:15 ` lyude [this message]
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=4a55a48948a1f01686b0471307b6fc2d52be7896.camel@redhat.com \
--to=lyude@redhat.com \
--cc=apw@canonical.com \
--cc=corbet@lwn.net \
--cc=federico.vaga@vaga.pv.it \
--cc=jkoolstra@xs4all.nl \
--cc=joe@perches.com \
--cc=kees@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=sashal@kernel.org \
--cc=skhan@linuxfoundation.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
all inboxes | Powered by JetHome®