All of lore.kernel.org
 help / color / mirror / Atom feed
From: Troy Benjegerdes <hozer@hozed.org>
To: Theodore Tso <tytso@mit.edu>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	"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: Wed, 21 Oct 2026 16:21:49 +0000	[thread overview]
Message-ID: <atjmnZl3tQ_1uaSJ@false> (raw)
In-Reply-To: <atggaWq0EU6Km8r0@mit.edu>

On Tue, Oct 20, 2026 at 10:54:40PM -0400, Theodore Tso wrote:
> 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.  :-)

Where's the job board for this. Or if you know of some developers that
want to come to a farm and work on RiscV-linux farm robots I can provide
food, housing, and whatever my experience is worth.

> 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

Those newcomers need viable paths for employment, at least in the
current system. I think if AI companies want to maintain their sky-high
stock valuations, there will have to use some of that theoretical market
cap by actually committed to resolving and paying off technical debt.

What if we had a "pay-per-patch" model? Would this help or would it just
turn into a game where whomever has the most money gets their patches 
reviewed?

  reply	other threads:[~2026-10-21 16:21 UTC|newest]

Thread overview: 82+ 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-20 21:15                 ` Laurent Pinchart
2026-10-21  2:54                   ` Theodore Tso
2026-10-21 16:21                     ` Troy Benjegerdes [this message]
2026-10-23 16:44                   ` Lorenzo Stoakes (ARM)
2026-10-25 21:32                     ` Jori Koolstra
2026-10-26  9:45                       ` 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-21 16:07                 ` Troy Benjegerdes
2026-10-26 19:04                   ` lyude
2026-10-26 19:39                     ` Linus Torvalds
2026-10-26 19:53                       ` Joshua Peisach
2026-10-26 20:24                       ` lyude
2026-10-26 21:29                       ` Jori Koolstra
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
2026-10-22 13:20           ` Troy Benjegerdes
2026-10-23 17:36             ` lyude
2026-10-26 19:58 ` [PATCH] docs: remove Assisted-by references Joshua Peisach

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=atjmnZl3tQ_1uaSJ@false \
    --to=hozer@hozed.org \
    --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=tytso@mit.edu \
    --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 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.