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 00:28:34 -0400 [thread overview]
Message-ID: <atbm7w6WFSnwpduj@mit.edu> (raw)
In-Reply-To: <20261019224448.GC15441@killaraus.ideasonboard.com>
On Tue, Oct 20, 2026 at 01:44:48AM -0500, Laurent Pinchart wrote:
> > Recently 2 people sent 1,000 patches over 2 hours. Care to check each and
> > every patch for 'quality'? :) Only the beginning.
>
> That's the kind of behaviour that should be easy to detect, and I have
> absolutely no issue with sending all those patches to /dev/null. This is
> script kiddies behaviour, not the work of someone with good intentions.
> Ignoring those patches is not "collateral damage".
Well, let's take the reverse. Suppose there are 500 newcomers who
have each sent two patches each in the same time period. This is
going to put the same stress on the reviewers and maintainers. Of
those 500 newcomers, there will undoubtedly be few (single digit
percentage) that will eventually become valued reviewers, and somewhat
larger percentage that will become regular code contributors of
quality improvements.
These percentages were always there pre-AI, but there were much fewer
newcomers per unit time. So this increase of new comers has its good
side --- it means we have the opportunity to significantly grow our
community. But it also has its shadow side, which is when we only
have a newcomer every month or two or three, the overhead of trying to
engage with a newcomer isn't that great, even if the vast majority of
them disappear after the maintainer attempts to work with them. And
if that happens, we just shrug and move on.
But if there is 10x or 100x the number of newcomers, it puts a huge
strain on the pre-existing community to engage with these newcomers.
And when we get newcomers who send patches like this:
> We could go a step further. There's also an increase in patches from
> newcomers who send a few patches only, with the usual signs of not
> understanding what they're doing: code changes that give an eerie
> feeling, very large comment to code ratios, and commit messages longer
> than the three volumes of Lord of the Rings combined.
.... the question is the probability that newcomers whose first few
patches look like this compare with the probability of newcomers who
first patches are 100% human generated?
I don't know the answer to this question, but clearly some people
believe that the probabilities are different, and so if they need to
make some lifeboat choices about which newcomers to engage with first,
it might influence their choices.
Even if doesn't, the reality is that with a huge influx of patches and
newcomers, maintainers' time is finite and expecting them to engage
with all newcomers, and review all patches promptly is a recipe for
burnout. So "collateral damage" isn't just not just newcomers needing
to wait weeks before someone gets back to them (and some might never
get a reply if their patches get lost in someone's inbox), although
that can certainly be collateral damage. It's also the potential of
maintainers getting burned out; that can also be collateral damage.
And having someone claim that it's the maintainers "fault" for not
building up the reviewing community is also not helpful. We are where
we are, and as much as I would hate to lose a potential contributor
who gives up because they don't get attention right away, when only a
percentage of these newcomers become regular contributors a certain
amount of self-care and preserving the maintainers' sanity might have
to take higher priority.
Don't get me wrong. Getting a large number of contributions, even if
not all of them are high priority fixes and/or high quality
contributions, and having a large number of newcomers is a ***good***
problem to have. And I'm thankful that we have it. But it still can
be a problem that we need to solve, one way or another.
- Ted
next prev parent reply other threads:[~2026-10-20 4:30 UTC|newest]
Thread overview: 67+ 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-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 [this message]
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=atbm7w6WFSnwpduj@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®