From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=18.9.28.11 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792470651; b=O3pCvu5yaP7i0dVfx3I3IQPI8NNEYG39CcKQNY2oN9MAnxWsEW5+ImQDAyDxuyuUW2iM a5BFFB/91g0QxovVd+tTqOARCiHnK/xyMwpwmH74ruZp9CpDmOj8iNBKtHkZNRvR12+Af cl/lmBi4w/wAsItLjVN8lRyhCp8noh/sTUSrFLSlGO8kJvGPqGJ/XlcWaReoKT2nUap7v hsrTXcTNs4Dt6o89qyFDMKU1jspLE5HI7fWgnn31jtWMja0tc/yD5qR+XNGrPDnm+pYzV ic+yVjdei8vU7oQtfpXdKhhd/ipG/SF/jyLMTm1PBtBh6pfKf5ezIfA/ZBerTlywQxg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792470651; h=DMARC-Filter:Received:DKIM-Signature:Received:Date:From:To:Cc: Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; bh=9j3OvoxTGWGD26yaKNg6HrpKJGkRBiGsb2UWwwP5GFA=; b=SUgDlESus2E3+Tf5/4Ay8fjn4oGhkGJHryEjBDgMq3OJRoYRT/F+Sh2nRFBJOVev/ypI oaOChVM9qouSUHgINvjlpCcYrXcXI8ftXCiZChBIgCEBD3MAruK2N/u4ytXE78+d5UejE VWJj/52VwdsplhqYwmW3Os7Rjv68j43SDbYSqyBqQMS7G/DrQuKXse6t4jyCrYxkn4uj9 rwzPXqKmyulLUlrV2QA8qP8Bj+fEgn7+M+JvqJxXG+HgQnOYRDUIP17MLS4YYYuD4bG04 1RQf8enW9fOT6D8vn3V7ajcawWVnPOcnpwM6MednI+Jh5xFEXkhbozXiG+OavoAOB8w== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; dkim=pass header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=UJeI0CaH; arc=none smtp.remote-ip=18.9.28.11 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 595FD606A31D for ; Tue, 20 Oct 2026 04:30:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 595FD606A31D Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=UJeI0CaH Received: from macsyma.thunk.org (pool-173-48-113-115.bstnma.fios.verizon.net [173.48.113.115]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 69K4TZx2005333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Oct 2026 00:29:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1792470586; bh=9j3OvoxTGWGD26yaKNg6HrpKJGkRBiGsb2UWwwP5GFA=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=UJeI0CaHr8FD1fkb9npYaLKCJIGT3pYr63clbA+4mvZ4Uj+fb0XxcWtIt4wQPGks4 Rk3uDxtlGpuYS7vrPwm7uHAnHPJt/5MPHuL95WfdxWqKAjhwef0ZuP9lcdmOD/JMzu J8IffN4VnTeTFKeJoED0wVkhIVQKjxwKsC0vjKNIdCyQLkfItnvWv4leaR4GAksmKj lUPKmnHKqFDaTj+2uUmq2Qub2zAx8P6bMQY9dpYF2HVjZY50mEgQ/EeBn6oBfxN2bX wy+6l4B2teOukwF7dZkknQNeQVVy8ejknEhipJKPUG7znpBwCTNbVA57FzFg70H7uK j5tv7qYUzLGEg== Received: by macsyma.thunk.org (Postfix, from userid 15806) id 07C0021B27DD; Tue, 20 Oct 2026 00:28:35 -0400 (EDT) Date: Tue, 20 Oct 2026 00:28:34 -0400 From: "Theodore Tso" To: Laurent Pinchart Cc: "Lorenzo Stoakes (ARM)" , Krzysztof Kozlowski , Sasha Levin , 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 , Linus Torvalds , Justin Stitt , Carlos Maiolino , Jakub Kicinski , Jori Koolstra , Brian Foster , Christoph Hellwig , David Disseldorp , Mark Brown , Jani Nikula , Jens Axboe , "David Hildenbrand (Arm)" , Vlastimil Babka , "Christian Brauner (Amutable)" Subject: Re: [PATCH] docs: remove Assisted-by references Message-ID: References: <20261009083137.3-1-sashal@kernel.org> <0914a106-bacf-4d95-854a-bfeefbff62a4@kernel.org> <20261013123132.GC4214@killaraus.ideasonboard.com> <20261013131243.GM56180@killaraus.ideasonboard.com> <20261019224448.GC15441@killaraus.ideasonboard.com> X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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