All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mark Brown <broonie@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
	ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc
Date: Fri, 17 Jul 2026 10:09:56 -0400	[thread overview]
Message-ID: <alo3tBAc_tBNgtg0@laps> (raw)
In-Reply-To: <20260716203810.GF1735001@killaraus.ideasonboard.com>

On Thu, Jul 16, 2026 at 11:38:10PM +0300, Laurent Pinchart wrote:
>Hi Sasha,
>
>On Thu, Jul 16, 2026 at 12:24:45PM -0400, Sasha Levin wrote:
>> On Thu, Jul 16, 2026 at 05:08:40PM +0100, Mark Brown wrote:
>> >On Thu, Jul 16, 2026 at 11:28:25AM -0400, Sasha Levin wrote:
>> >> On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
>> >
>> >> > - 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
>> >
>> >> >  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?
>> >
>> >> Shouldn't it be a merits question rather than a tools question?
>> >
>> >> If the commits are correct, does it matter if they were written with an LLM? we
>> >> can insist more on supplying tests and demonstrating correctness, something we
>> >> seem to be doing quite rarely right now.
>> >
>> > The issue (which a number of projects are facing) is as much one of
>> > volume as anything else, the code generation machines are enabling the
>> > generation and submision of volumes of code where things were previously
>> > constrained by human factors.  It can turn into a bit of a DoS.  I don't
>> > have any particularly bright ideas here but it's definitely a thing.
>>
>> Sure, we're seeing quite the increase in patch submissions, but I'm trying to
>> argue that the issue isn't a new one: lack of maintainers, trusted reviewers,
>> and maintainer burnout has been a topic at each kernel summit for as long as I
>> can remember. AI just kicks it up a notch.
>>
>> My concern is that if we focus on the AI aspect, we still won't be solving the
>> underlying issue.
>>
>> I'm hoping we can figure out how to get maintainers great tooling, testing, and
>> community, rather than figuring out how to block a developer who uses LLM.
>> Maybe AI would actually be a great catalyst for that as well?
>
>Didn't you argue in another part of this thread that we're in no danger
>of being depending on AI for our processes ? I see a contradiction here.

Hey Laurent,

Not sure I follow here.

My thinking was that trying to improve our processes and tooling has been a
topic for the past decade or two. One of the times we discussed it was the 2019
maintainer's summit (https://lwn.net/Articles/799134/) where we decided to
create the workflows@ mailing list to share our tooling and workflows. Not much
of that has been happening :)

In the past year or two I was able to rewrite most of my ugly scripts, automate
so many of the processes I used to do manually, and just improve so many
quality of life items thanks to AI. Look even at the CVE process that was
created last year: so much of the infrastructure used to drive it was created
with AI.

Now, if AI suddenly goes away tomorrow it'll suck for me, but I'll just go back
to writing my tools manually like I did before. I don't think that I somehow
became "dependant" on it.

-- 
Thanks,
Sasha

  reply	other threads:[~2026-07-17 14:09 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-16 15:09 [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc Jonathan Corbet
2026-07-16 15:28 ` 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 [this message]
2026-07-17 14:25       ` Mark Brown
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-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-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-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

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=alo3tBAc_tBNgtg0@laps \
    --to=sashal@kernel.org \
    --cc=broonie@kernel.org \
    --cc=corbet@lwn.net \
    --cc=ksummit@lists.linux.dev \
    --cc=laurent.pinchart@ideasonboard.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.