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=1792551401; b=HHXcFyJScHnPTOyHRQ/PIXs/TFPB+mkSQfXGlInFE/WGLOm/p9Ww8ceQTC/GXGae/stI aNuR9dVdWPQQt2br8BrQnnQ739t61P2DAtqQUgm9/0h3264DfLrVzuYzZRNAE4oqSIkGo FpEOPkuO5q+4QjUTHd9awr3m3cBdib/hPm9BlbVp1RUFm10bYM6/YVlJApQviz9Vo7rZc hhkkk34v7WuQsA4gs7TkEdxC4E2BcicSN7mI+eh8fiUap+U0BKjoDZfFoHG5a7LP5IgyZ q7Wo/KQdtHSQoxD7GSNOe1S2UmDgqdMh5P5F4ybCXurO5x9XoxpGBxwE8MdVDY6s04w== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792551401; 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=adBKmkAuQPG1pNEqNQsG9z5fLXrMmEzel894oEpnrT8=; b=xs7zamT80KNJkPFGn6L9Qq3/PJN0tu1k08+bO05Hvq/bfj5aycvLe4/rl/OBMWFU52ci Od/H3Tqq+hGCNV9zWzzkVKbg3i+414zvTcobPT3S1Ch5YqguNoqSGx7VVyqo4ruKPQlNI msuMlVARJTKSwKBd3wi3GGtxvgtsUP4C7c7HqPyPNGKElk5gKc4RUk0J8cc61FJCg7uiM tArSI1MDuSsyzWGizVQH1Goloirc3+RebnggM3zyFuR3ddmdgUc/fuID6sAjdo5NbiNhR GnJ+W0yPPmKgXGbCpi3DEjkHKMq8BwBXSldUu/nzCuA1VmKhZw6bYasuh3vgi/P+a4g== 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=UHDGXmxu; 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 29AB9606A321 for ; Wed, 21 Oct 2026 02:56:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 29AB9606A321 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=UHDGXmxu 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 69L2tfaT032022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Oct 2026 22:55:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1792551351; bh=adBKmkAuQPG1pNEqNQsG9z5fLXrMmEzel894oEpnrT8=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=UHDGXmxuazjo9kg0UJBMosrzyJJQ0GTYgx9rT8vBbYtt1yEdHYvoklxa4vdyHRQnJ 6vDWhg5S/uuxmRw5coSoUvvHFJe2htO1nXFxGFCZg2EmlLNIVkfZRukUG3QOBhEV/1 6FJQnYs/Xqcd+MSvYsgkwGArnqXakd4fNMAWvyFh+Gdg17IST3YkGJfqF+KkkUdqQ8 rYfUII2iGEx0y+XqD85X5xCo6r1q16/MXlN7GtZvLza03pIAuKtNLE3us7XLz2lRa7 Q3gRg43M+YPrdYwYM0ZWJSc4ZM1FA8Et4o2GES5cPhiJJsblvciW3SvaXwm4g0WZ2Z IIznWg5R7Njjg== Received: by macsyma.thunk.org (Postfix, from userid 15806) id 04FB821CF0C7; Tue, 20 Oct 2026 22:54:41 -0400 (EDT) Date: Tue, 20 Oct 2026 22:54:40 -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> <20261013173240.GK4214@killaraus.ideasonboard.com> <20261020211532.GD15441@killaraus.ideasonboard.com> X-Mailing-List: workflows@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: <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