From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A738F30F951; Thu, 8 Jan 2026 18:19:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767896345; cv=none; b=gCjc7YsgInRinZ2rF9O3mkoMmH6ascXJClfml8echKJdFx5IWCe5PXds7DUhiIVl2VOqinGDTy3lGc3Gm7YRz8gn6hFliyKaTsayymHfMhoJ/G/l+PwNNQl5RqpIG7IqDk0aqrJ+mIvVRUKsWFZDqzZe/IgKq0IE4skvjO7rkhU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767896345; c=relaxed/simple; bh=lB9QMSDIyOoHx8iLunAZ/h7Z9GbsyWh5cTFPoWF5x6k=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=istETtkw8HF0IROPBZTSwK3nCXLU/4pqNz6Jj0tWs8PSfsAoQvCBNUN2K2172utKN74jRTkEC42UbhQW6pXEuePZW1KSvFuaX6lKkbi6TiiBtsSfHvOnVC+5S53YoUBZtPGlbzRTojWivtv4rri2I772CTM7b5Vg9h+y0K54Izs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; arc=none smtp.client-ip=216.40.44.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Received: from omf06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0E6028ABEB; Thu, 8 Jan 2026 18:19:01 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf06.hostedemail.com (Postfix) with ESMTPA id 6660C2000F; Thu, 8 Jan 2026 18:18:57 +0000 (UTC) Date: Thu, 8 Jan 2026 13:19:26 -0500 From: Steven Rostedt To: Lorenzo Stoakes Cc: Dave Hansen , Dave Hansen , linux-kernel@vger.kernel.org, Shuah Khan , Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , Luis Chamberlain , SeongJae Park , Dan Williams , NeilBrown , Theodore Ts'o , Sasha Levin , Jonathan Corbet , Vlastimil Babka , workflows@vger.kernel.org, ksummit@lists.linux.dev Subject: Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content Message-ID: <20260108131926.59b456fc@gandalf.local.home> In-Reply-To: References: <20260106205105.4037716-1-dave.hansen@linux.intel.com> <1e982055-47c2-43d1-a919-93b3e59f2ed0@lucifer.local> <93aadf2b-0df4-49eb-91fd-b401b44ce3af@sr71.net> <1c74353c-40de-4d0b-a517-92a94f8b4af8@lucifer.local> <20260107165816.63ff25ac@gandalf.local.home> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: workflows@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspamout07 X-Rspamd-Queue-Id: 6660C2000F X-Stat-Signature: e5xg6gwac6bj799kjoqippj7awa4d947 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX1+4Avba8VeZkPzKBjEiV0TCiEaIttOwGAI= X-HE-Tag: 1767896337-58098 X-HE-Meta: U2FsdGVkX18oNFFK86xlhyl/QFoz41lmRK3HyYqeS8/74EHrWz8UxqZ90KUMg+gZ+ytAc7rDape5EtOEBkZtquF9cBPdNhs609mZKIURxDdbqr1HZRBp/7ZHY6PjYNCxXlTureRrsr0sMdguvps2Byp+4KpupbGzQeqpkOW5DZ2OQUh00Vk+4drV1rOn6mND+/akQR2ywZnqhYQfb1kTIGxfMAtYzICJkeorWh7ebOkrblnunZ/gQlHTK9xKkRhXGVYeAexy2Q2Rs8go4A5SJBa25z9FUGGxpB0AhAVBmp+mJVq4Jp5E3BiXE8yDQuE18mYE+8cfD4PIJbzZEdxzPvCiBFotbHjK On Thu, 8 Jan 2026 11:29:47 +0000 Lorenzo Stoakes wrote: > > But one thing I learned about my decade on the TAB, is don't worry about > > things you are afraid might happen, just make sure you address what is > > currently happening. Especially when it's easy to update the rules. > > I mean why are we even writing the document at all in that case :) why did this > discussion come up at the maintainer's summit, etc. What happened that started this discussion was me reading about an AI patch that was submitted and accepted without the maintainer knowing that the patch was 100% created by AI. That maintainer just happened to be me! I made a stink about not disclosing the fact that the patch was generated by AI. I wanted full transparency. A long discussion started there where we noticed that we have no written policy on transparency of tooling used to create patches and wanted to fix that. That was the reason this all started, but it expanded to "Oh we need to document our policy on AI too". That was an after thought. See why I'm still pushing to only document what our current policy is. > > I think it's sensible to establish a clear policy on how we deal with this > _ahead of time_. Why? We don't know what is going to happen. We are only assuming things are going to be a problem, where it may never be. > > And as I said to Linus (and previously in discussions on this) I fear the > press reporting 'linux kernel welcomes AI submissions, sees it like any > other tool'. But this document doesn't even say that. It's only expressing in writing what our policy is on transparency of using tooling where AI is just one more tool. AI submissions have already been done. It's only accepted after the normal process is followed. -- Steve