Re: [PATCH] docs: remove Assisted-by references

[Theodore Tso]

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