On 7/2/26 12:04, Lorenzo Stoakes wrote: > (thanks for the cc-!) > > On Thu, Jul 02, 2026 at 09:46:37AM +0200, David Hildenbrand (Arm) wrote: >> On 7/2/26 09:27, Christian Brauner wrote: >>> >>> I think we should just drop any attribution as a general kernel-wide >>> rule and let subsystems require them as needed. Then you can have all >>> the complexity in mm for this that you think is needed for your >>> workflow to function. This is precisely what the subsystem profiles are >>> for. So maybe just add: > > A single comment is complexity?
I think Christian meant more elaborate rules. More than just "If you used LLMs, disclose how you used them." >> >> I'm not really sure if having (more?) subsystem-specific tags is the way to >> go. >> (below) >> >> So either we find a very simple, kernel-wide rule for such tags, or we drop >> them >> entirely. > > Yup I couldn't disagree more with Christian here, the whole thing feels like > trying to 'wish away' the AI issue, and now punting off to subsystem > maintainers... > > Subsystems impact each other. Right now I'm writing a series that changes > driver > code so we can enforce some sanity in mm APIs. > > I've had to interact with fs code quite a bit that uses mm logic. > > It's all interconnected, and one subsystem let's say going with 'let it all > in' > say, impacts another. > > Yes some people lie about it, but having the guidelines only STRENGTHENS our > position on that, and I've seen that in practice. > > So yeah, sorry, I think it's beyond silly to push back on requesting somebody > disclose how much of a patch/series was AI generated. > > And [0] already essentially says people NEED to do this now. But that doc has > been rather downplayed unfortunately I think. [...] >> I agree on the "enforce" aspect. It's impossible, but it's still easy to >> catch >> people using AI irresponsibly today ... and that's what we care about. Not >> people that know what they are doing using AI responsibly. > > For me it's about empowering maintainers to push back. Right, but I suspect maintainers do have this power already, it's just not exercised that often on obvious AI slop yet. > >> >>> >>> If the information is mostly useful during review then I still would >>> question why it has to end up in our git logs. It's completely >>> irrelevant information imho. >> >> Fully agreed. In the tree it's irrelevant. > > Not sure about that, if it turns out AI-generated patches are causing 95% more > bugs say that's pretty useful information no? Well a) You don't know how much AI was used. In particular, it could just slip in as the submitter tries to untangle some of the mess the AI created (so not AI's fault). Or the submitter just used it to write+translate the patch description. Really, the tag itself doesn't tell you much as it stands, which is the biggest problem I am having with it. b) You don't catch all the cases where people didn't use the tag. > > Or if you find that a patch somebody sent from another subsystem that has a > lassez faire approach to AI slop completely breaks you in some subtle way, > isn't > it easier to push for a revert if you see it's LLM-generated? The information would have to be had from the linked mailing list posting. Given that some subsystems already started suppressing the tags when applying patches, that doesn't really help ... :/ > > And is it really that egregious to include a tag? You can ignore it if you > don't > care. I hate the current tags as they are. The question I am asking myself: assume we stop using the Assisted-by for LLM stuff. What to do with the other tools? Why are LLMs suddenly no longer a tool to mention there. -- Cheers, David
