On Fri, Jan 09, 2026 at 02:00:39PM +0300, Dan Carpenter wrote: > On Fri, Jan 09, 2026 at 07:48:35AM +0000, Lorenzo Stoakes wrote: > > +cc Jens as reference him > > > > On Thu, Jan 08, 2026 at 03:14:37PM -0500, Steven Rostedt wrote: > > > On Thu, 8 Jan 2026 11:50:29 -0800 > > > Dave Hansen <[email protected]> wrote: > > > > > > > On 1/8/26 11:23, Lorenzo Stoakes wrote: > > > > > I'm also not sure why we're losing the scrutiny part? > > > > > > > > > > Something like: > > > > > > > > > > +If tools permit you to generate series entirely automatically, expect > > > > > +additional scrutiny. > > > > > > > > The reason I resisted integrating this is it tries to draw too specific > > > > a line in the sand. Someone could rightfully read that and say they > > > > don't expect additional scrutiny because the entire series was not > > > > automatically generated. > > > > I mean you are making an absolutely valid point, I'd say that'd be a rather > > silly conclusion to take, but we have to be wary of 'lawyering' the doc > > here. > > > > > > > > > > What I want to say is: the more automation your tool provides, the more > > > > scrutiny you get. Maybe: > > > > > > > > Expect increasing amounts of maintainer scrutiny on > > > > contributions that were increasingly generated by tooling. > > > > > > Honestly that just sounds "grumpy" to me ;-) > > > > > > How about something like: > > > > > > All tooling is prone to make mistakes that differ from mistakes > > > generated by humans. A maintainer may push back harder on > > > submissions that were entirely or partially generated by tooling > > > and expect the submitter to demonstrate that even the generated > > > code was verified to be accurate. > > > > > > -- Steve > > > > I don't really read that as grumpy, I understand wanting to be agreeable > > but sometimes it's appropriate to be emphatic, which is the entire purpose > > of this amendment. > > > > Taking into account Jens's input too: > > > > +If tools permit you to generate series automatically, expect > > +additional scrutiny in proportion to how much of it was generated. > > + > > +As with the output of any tooling, the result maybe incorrect or > > +inappropriate, so you are expected to understand and to be able to defend > > +everything you submit. If you are unable to do so, then don't submit the > > +resulting changes. > > + > > +If you do so anyway, maintainers are entitled to reject your series without > > +detailed review. > > This is too subtle. In real life if we suspect a patchset is AI Slop, > then we're going to reject the whole thing immediately. No one is > going to review all fifteen patches one by one as if we're searching > through monkey poo for edible grains of corn.
I'm trying to compromise as the general direction on this document is to be very soft (see the suggested edits so far). I get why, but the entire purpose of this amendment is to put emphasis and really to stand up as a community and to say clearly this isn't something we want. > > The AI slop patches I've seen were not bad actors. Someone saw a > TODO in the file and thought that AI could solve it. The patch > compiled, it was formatted correctly and the commit message sounded > confident so they sent it. Yes exactly this. Exactly. I've said it elsewhere, but: a. People who have good intentions who will take this as a green light to just send out fully LLM generated stuff. b. Press coverage (it's already happening) will essentially signal it's a green light on this. For e.g.: https://www.phoronix.com/news/Torvalds-Linux-Kernel-AI-Slop https://www.theregister.com/2026/01/08/linus_versus_llms_ai_slop_docs/?td=rt-3a > > To me the audience for this is maybe a team working on AI and they > don't have any kernel developers on staff so they assume they're being > helpful sending unreviewed patches. The message should be that every > patch needs to be reviewed carefully before it is sent upstream. I've > been asked to review patches like this in the past. Get outside help > if you need to, but every patch needs to be reviewed. Yes exactly. But also it's useful when dealing even with bad actors to point at the community _actually taking a postiion_. And frankly on waiting for it to 'get worse' (i.e. to get like basically the rest of open source) - I have little faith the document really will be updated to say anything forthright at least at any speed, and by then it'll be too little too late. The idea the kernel community taking a position doesn't have any impact is simply false. I think far too much thinking in terms of how computers are going on here, and too little about how people are. > > regards, > dan carpenter Cheers, Lorenzo
