mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: lyude@redhat.com
To: Jori Koolstra <jkoolstra@xs4all.nl>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Lorenzo Stoakes <ljs@kernel.org>
Cc: Kees Cook <kees@kernel.org>, 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:50:00 -0400	[thread overview]
Message-ID: <c0e0a34aa136104c9644e007032b98cf0d56417a.camel@redhat.com> (raw)
In-Reply-To: <28216768.791900.1791897606751@kpc.webmail.kpnmail.nl>

On Tue, 2026-10-13 at 15:20 +0200, Jori Koolstra wrote:
> 
> > Op 13-10-2026 15:10 CEST schreef Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> > 
> >  
> > On Tue, Oct 13, 2026 at 03:03:08PM +0200, Jori Koolstra wrote:
> > > > Op 13-10-2026 14:55 CEST schreef Laurent Pinchart:
> > > > On Tue, Oct 13, 2026 at 02:28:43PM +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
> > > > > 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.
> > > > 
> > > > The absence of the tag on a suspicious series offered a low-effort way
> > > > for maintainers to push back. What's the proposed low-effort replacement
> > > > ?
> > > 
> > > To ignore it, really. Even less effort :)
> > 
> > Are you saying that we should ignore series when we have even a slight
> > suspicion they're not perfect ? If not, I don't understand what you're
> > proposing exactly.
> > 
> 
> I am saying it is up to the maintainer. The word is out and we are allowed to
> ignore poor contributions, in particular if they are LLM generated. The whole point
> is that in the past poor contributions were still a signal someone was trying and
> it might be worthwhile to help them to grow. It is not that signal anymore per se.

I consistently see new contributors getting involved in the kernel who
are not using LLM tooling. This is still very much a thing, and I would
advise against missing the forest for the trees because the new
contributors with LLM tooling are so much louder then the ones without
because only one of those two groups can send patch bombs at a moment's
notice that require going through in order to know whether or not to
ignore it.

> We need other avenues to identify talent. The kernel mentorship program is one of
> those, as is showing up in person at conferences.

This is an open source project, submitting work - even for people using
LLMs - should be one of the ways that people can get involved. It has
far less barriers to attending a conference in person, and not all
contributors can or want to be at an in-person event just to contribute
to a project.

Also - I've been a kernel maintainer and I've never been at LPC. I know
plenty of people who have never been to LPC, it is more then just
financial constraints. If an LPC is so truly representative of
maintainers at large here, then why are there maintainers responding
here with objections? What challenge would there be to actually opening
this discussion up to all of the other maintainers who were not there?

> 
> The tag helped some maintainers to push back (like Lorenzo). The tag isn't needed
> anymore, because the push back isn't needed. I think that's an improvement, and at
> any rate was inevitable.

It is, though. I want people who actually took the time to learn how to
contribute to a codebase I maintain to actually have some kind of
priority over new contributors using LLMs, because we still attract new
contributors and talent who don't want anything to do with LLMs.
Projects like Asahi I've pretty much only started getting involved in
because of their no LLM policy.

Have you considered that maybe this is a self-fulfilling prophecy that
is partly the result of a lack of maintainers and the difficulty
imposed on new contributors getting involved because of policies like
"just ignore work and don't respond if it looks like slop"? The person
who could contribute and decides it's not welcoming, or there's not
much chance of their work getting reviewed, etc. is not typically the
person that says so on a mailing list, or as I've started seeing - just
simply doesn't want to look at the project because they are not
enthusiastic about working with LLMs in their spare time or ever. More
likely, they just leave and don't contribute.

Has the rest of the kernel really gotten so bad at attracting new
contributors outside of LLM spheres you just, don't get these people
anymore?

> 
> Best,
> Jori.


  parent reply	other threads:[~2026-10-19 16:50 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 [this message]
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

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=c0e0a34aa136104c9644e007032b98cf0d56417a.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=laurent.pinchart@ideasonboard.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ljs@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®