ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: ksummit@lists.linux.dev
Subject: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc
Date: Thu, 16 Jul 2026 09:09:27 -0600	[thread overview]
Message-ID: <87wluv7yzc.fsf@trenco.lwn.net> (raw)

The use of LLMs in the development process appears to be a clear theme for
the upcoming summit.  On top of what others have already suggested, I think
we may want to consider these questions:

- Do we want to continue naming specific LLMs in the Assisted-by tags, or
  put something more generic?  I *think* that this thread:

    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/

  reached a consensus that "Assisted-by: LLM" was better than what we
  require now, but it might be good to ratify that in this setting.

- There is a lot of LLM-generated code that lacks an Assisted-by
  disclosure.  Often, that seems to be the result of ignorance of the
  rules; those contributors will start adding the tags when informed of the
  requirement.  But others just lie about it.  A rule that is widely
  ignored does not help anybody.  Can we come up with a way to get better
  compliance, or should we just drop the tag entirely?

- There are many first-time contributors coming in with LLM-generated
  patches.  At times, I could swear that every one of them is focused on
  documentation typos, but the truth of the matter is that they are
  reaching into subsystems all over the kernel.  We have some brand-new
  contributors making significant changes to dozens of subsystems.  An
  experienced developer would be hard-put to truly understand what those
  changes are doing; a newcomer is unlikely to have that understanding,
  and is unlikely to be around to fix eventual problems.

  Our maintainers are not scaling to handle this new flood, and I fear we
  are going to see some unfortunate things merged.  One LLM-driven newcomer
  recently nearly succeeded in establishing himself as the maintainer of
  lib/.  How do we hold the line against this stuff while remaining open to
  new developers?

- Our process is becoming increasingly dependent on proprietary tools.  We
  have done that before and, in 2005, it went pretty badly for us - and
  could have been worse.  How do we prepare for the inevitable rugpull?  I
  raised this last year, and it was largely brushed off, but I still think
  it's something we should be concerned about.

That's probably enough :)

jon

             reply	other threads:[~2026-07-16 15:09 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-16 15:09 Jonathan Corbet [this message]
2026-07-16 15:28 ` [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc Sasha Levin
2026-07-16 16:08   ` Mark Brown
2026-07-16 16:24     ` Sasha Levin
2026-07-16 20:38       ` Laurent Pinchart
2026-07-17 14:09         ` Sasha Levin
2026-07-21 23:15           ` Laurent Pinchart
2026-07-22  0:23             ` Guenter Roeck
2026-07-17 14:25       ` Mark Brown
2026-07-21 23:58       ` Jori Koolstra
2026-07-22  0:57         ` Linus Torvalds
2026-07-22 14:20           ` Trond Myklebust
2026-07-23 14:15             ` Mark Brown
2026-07-22 17:48           ` Konstantin Ryabitsev
2026-07-22 19:15             ` Linus Torvalds
2026-07-23  0:26             ` Kees Cook
2026-07-23 13:10               ` Steven Rostedt
2026-07-23 14:30           ` Jori Koolstra
2026-07-16 18:36   ` Jonathan Corbet
2026-07-16 19:53     ` Mauro Carvalho Chehab
2026-07-16 23:59       ` Theodore Tso
2026-07-17  0:58         ` Mauro Carvalho Chehab
2026-07-17  2:27           ` Theodore Tso
2026-07-17  7:19             ` Mauro Carvalho Chehab
2026-07-19  9:01             ` Mauro Carvalho Chehab
2026-07-21 18:21               ` Mauro Carvalho Chehab
2026-07-18  9:26           ` Takashi Iwai
2026-07-19  9:29             ` Mauro Carvalho Chehab
2026-07-22  9:53               ` Takashi Iwai
2026-07-17 13:55         ` Konstantin Ryabitsev
2026-07-17 14:24           ` Andrew Lunn
2026-07-17 14:32             ` Konstantin Ryabitsev
2026-07-17 14:50               ` Andrew Lunn
2026-07-17 20:21           ` Theodore Tso
2026-07-18 12:54             ` Mauro Carvalho Chehab
2026-07-16 20:05     ` Bart Van Assche
2026-07-16 20:52       ` James Bottomley
2026-07-16 20:23     ` Liam R. Howlett
2026-07-17  7:49       ` Laurent Pinchart
2026-07-17 15:55         ` Liam R. Howlett
2026-07-17 11:57       ` James Bottomley
2026-07-17 15:53         ` Liam R. Howlett
2026-07-17 18:12           ` James Bottomley
2026-07-17 18:27             ` Dan Carpenter
2026-07-17 18:42               ` James Bottomley
2026-07-18  1:13                 ` Theodore Tso
2026-07-18  3:07                   ` James Bottomley
2026-07-17 14:54       ` Johannes Weiner
2026-07-17 16:09         ` Liam R. Howlett
2026-07-16 21:23     ` Theodore Tso
2026-07-17 13:59     ` Sasha Levin
2026-07-17 14:09       ` Konstantin Ryabitsev
2026-07-21 23:24 ` Jori Koolstra
2026-08-08  8:45 ` Dan Carpenter

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=87wluv7yzc.fsf@trenco.lwn.net \
    --to=corbet@lwn.net \
    --cc=ksummit@lists.linux.dev \
    /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;
as well as URLs for NNTP newsgroup(s).