From: "Theodore Tso" <tytso@mit.edu>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Sasha Levin <sashal@kernel.org>,
corbet@lwn.net, skhan@linuxfoundation.org, rdunlap@infradead.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,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Justin Stitt <justinstitt@google.com>,
Carlos Maiolino <cem@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
Jori Koolstra <jkoolstra@xs4all.nl>,
Brian Foster <bfoster@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
David Disseldorp <ddiss@suse.de>, Mark Brown <broonie@kernel.org>,
Jani Nikula <jani.nikula@intel.com>, Jens Axboe <axboe@kernel.dk>,
"David Hildenbrand (Arm)" <david@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
"Christian Brauner (Amutable)" <brauner@kernel.org>
Subject: Re: [PATCH] docs: remove Assisted-by references
Date: Tue, 20 Oct 2026 22:54:40 -0400 [thread overview]
Message-ID: <atggaWq0EU6Km8r0@mit.edu> (raw)
In-Reply-To: <20261020211532.GD15441@killaraus.ideasonboard.com>
On Wed, Oct 21, 2026 at 12:15:32AM -0500, Laurent Pinchart wrote:
> I fully understand that many maintainers currently feel they're too
> pressured to invest time in the next generation. We need to find
> solutions to make that possible.
One possibility is to create tools and/or procedure to amplify signals
about which newcomers are most likely to become the next generation,
as opposed to someone who is just sending drive-by patches.
The reality is that the vast majority of first time patch submitters
won't become part of the next generation. So if we are getting 10x
the newcomers, if we can be more discerning about which newcomers we
invest in, the project won't die, even if we are ignoring, 3x to 5x
the number of newcomers.
> This is something we really need to improve quickly. Over the past week
> multiple active kernel developers asked me if I thought they needed to
> find a job elsewhere, thinking maintainers will now ignore anything but
> perfect patches and dismiss contributions from developers who don't use
> LLMs. That's a wrong impression (at least I very much hope so, and you
> clarified that you're not advocating for that), but it's a disastrous
> impression that many people got from the maintainers summit and the
> following mailing lists discussions.
If someone is an active kernel developer, presumably they already have
enough of reputation that they won't get ignored. The issue is really
going to be newcomers who don't yet enough of a reputation, not
"active kernel developres who are wondering if they need to find a job
elsewhere".
And if they have a job, meaning they are in the industry, hopefully
their employer is willing and able to hire a more senior kernel
developer with a reputation in the industry to help them out.
Fortunately, certain companies like Oracle have graciously been
releasing a lot of such talent on the market, so these people *are*
available. :-)
A senior kernel developer will be able to help introduce more junior
developers to the community, both online via e-mail and at conferences
such as Plumbers. More importantly, the more senior kernel developer
can help the more junior developer write cover letters which better
motivate why a particular patch is important. Half the problem is
that a lot of the "AI Slop" patches aren't particular important, and
in some cases, the business case has been wildly exagerated.
(For example, there was the patch which claimed to address a very high
severity "one click exploit" bug --- but the exploit required (a)
tricking someone to download a malicious file system image, and (b)
running a fairly obscure "tune2fs -U random" command on said image,
and (c) be stupid enough do it as root to justify the astronomical
CVSS score. By calling this a "one click exploit" with an extremely
high CVSS score, that engineer and their company has been forever
tainted in my eyes, and you can *bet* that I'm going to take any
patches from them far less seriously.)
Anyway, all of this might mean that someone who has zero prior
reputation, and doesn't have the $$$ to attend a conference, and who
isn't able to get a job at a company where a more senior kernel
engineer can introduce them to the community, and who can't get a
position at a mentorship program like Outreachy or GSOC might have a
much harder time to get a maintainer's attention. Yes, this will suck
for some newcomers; but so long as we get enough new blood from other
sources (such as new college grads working at a traditional Linux
company), it doesn't follow that just because we aren't engaging with
*every* *single* *newcomer* that it spells doom for the Linux kernel
community.
- Ted
next prev parent reply other threads:[~2026-10-21 2:56 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 8:31 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-20 21:15 ` Laurent Pinchart
2026-10-21 2:54 ` Theodore Tso [this message]
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
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=atggaWq0EU6Km8r0@mit.edu \
--to=tytso@mit.edu \
--cc=apw@canonical.com \
--cc=axboe@kernel.dk \
--cc=bfoster@redhat.com \
--cc=brauner@kernel.org \
--cc=broonie@kernel.org \
--cc=cem@kernel.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=ddiss@suse.de \
--cc=federico.vaga@vaga.pv.it \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=jani.nikula@intel.com \
--cc=jkoolstra@xs4all.nl \
--cc=joe@perches.com \
--cc=justinstitt@google.com \
--cc=krzk@kernel.org \
--cc=kuba@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=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
all inboxes | Powered by JetHome®