> Op 13-10-2026 14:55 CEST schreef Laurent Pinchart > <[email protected]>: > > > On Tue, Oct 13, 2026 at 02:28:43PM +0200, Jori Koolstra wrote: > > On Tue, Oct 13, 2026 at 01:25:59AM -0700, Kees Cook wrote: > > > On Mon, Oct 12, 2026 at 10:56:59PM -0700, Randy Dunlap wrote: > > > > On 10/12/26 9:24 PM, Kees Cook wrote: > > > > > On Fri, Oct 09, 2026 at 04:31:37AM -0400, Sasha Levin wrote: > > > > >> The Maintainers Summit reached consensus to deprecate the Assisted-by > > > > >> tag. Remove the documentation requiring it. > > > > >> > > > > >> Signed-off-by: Sasha Levin <[email protected]> > > > > > > > > > > Yup, it has become as redundant as specifying what editor I use. ;) > > > > > > > > > > Reviewed-by: Kees Cook <[email protected]> > > > > > > > > and for those of us who don't know details about the discussion, > > > > how is it redundant? > > > > > > No, I mean I use an LLM constantly for almost all aspects of my > > > development work, in multiple dimensions, so if the old tag requirement > > > held, my email body template would just put "Assisted-by: LLM" in there > > > because at the very least, it drove the build and test stage. It was > > > redundant in the sense of "yeah, of course I used an LLM at some point > > > for this patch". ("This tag means nothing *from* me") > > > > > > > Do you assume that everyone now uses it (LLM), just as everyone > > > > uses an editor? > > > > > > I don't make that assumption, but I always held the position that the > > > tag was meaningless because it's the human wielding it that matters: > > > they either sent a good patch or a bad patch, and if it was mangled by > > > gmail or an LLM, it doesn't really matter. ("This tag means nothing *to* > > > me") > > > > I think the tag did have a genuine purpose for a while. Now we have just > > decided to implicitly attach it to every new submitter (because > > basically that is the case.) The point was that a patch that was > > obviously LLM generated could be rejected for not carrying the tag, and > > a patch that carried the tag could be asked to explain further (if they > > had not done so.) Or at least, that is how I felt and have understood > > Greg, for instance :) > > > > Essentially, the way I read it, is that Linus said we don't need this > > roundabout way because we can just reject effortless LLM generated > > patches outright. This is good and an improvement. > > The absence of the tag on a suspicious series offered a low-effort way > for maintainers to push back. What's the proposed low-effort replacement > ? >
To ignore it, really. Even less effort :) > > What do you think about requiring people to explain how they used an LLM > > for code generation? I don't care if someone uses it for review, or > > brainstorming, or whatever, and I have never understood the tag to be > > required for that. But if the code is LLM generated, it would be nice to > > know for instance what prompts you used. We should have some way to not > > devolve into the maze that Jonathan Corbet has sketched, where no one > > really knows what's going on. > > Listing the prompts seems fairly useless to me. Not only do prompts > capture only a small submit of the information you would want (many > people use custom agent files with lots of rules that supplement the > prompts), they don't show that the submitter understands what they're > doing. > I'm not sure. Maybe requiring prompts is not the best way to go about it, it may be a lot of annoyance to go back through your conversations and see what prompts were relevant. I do think the prompts still likely show whether you understood what you're doing, assuming they were authentic. > Mesa has a policy that LLM-generated code *must* have a human-written > commit message. They go one step further by requiring all comments in > the code to also be human-written. That seems a better (but possibly not > good enough) way to try and gauge the level of understand from the > submitter. > Yes, requiring human written commit message sounds like a good idea. Only leaves the issue of people using LLMs for translate. But I think we could find a way around that. > -- > Regards, > > Laurent Pinchart
