On Thu, Jul 02, 2026 at 09:09:05AM -0400, Brian Foster wrote: > On Thu, Jul 02, 2026 at 01:18:06PM +0100, Lorenzo Stoakes wrote: > > On Thu, Jul 02, 2026 at 07:57:45AM -0400, Brian Foster wrote: > > > On Thu, Jul 02, 2026 at 10:44:09AM +0100, Lorenzo Stoakes wrote: > > > > On Thu, Jul 02, 2026 at 12:38:44PM +0300, Laurent Pinchart wrote: > > > > > On Thu, Jul 02, 2026 at 10:44:34AM +0200, Vlastimil Babka (SUSE) > > > > > wrote: > > > > > > On 7/2/26 10:12, Jori Koolstra wrote: > > > > > > > Ah, I still reigniting this discussion again :) > > > > > > > > > > > > > > What about a combination of what David and Jeff say? The whole > > > > > > > point > > > > > > > seems to me that the salient information is not that an LLM was > > > > > > > used (or > > > > > > > are we going to tag Sashiko as well or any other LLM-based code > > > > > > > review > > > > > > > tool?), but what is was used to do. This information may be > > > > > > > relevant for > > > > > > > how the review is approached. The latter should perhaps only be > > > > > > > in the > > > > > > > cover letter and then we can drop the assisted-by tags altogether. > > > > > > > > > > > > > > The question about enforcement remains. > > > > > > > > > > > > It's not possible to enforce it. People can deny it if the tag is > > > > > > missing > > > > > > and you confront them and even though the submission has many signs > > > > > > of being > > > > > > obviously LLM, there is no definite proof. We've seen (likely, as > > > > > > there's no > > > > > > proof!) that happen in mm. > > > > > > > > > > > > Such situation then penalizes those who disclose so obviously they > > > > > > won't. > > > > > > > > > > I think there's also a penality for those who don't disclose when > > > > > they're told they should: it will lower trust. Kernel development is > > > > > largely based on a trust model. If a contributor decides to adopt a > > > > > deceiptful behaviour, they can expect maintainers to raise the bar for > > > > > accepting patches, when not rejecting them outright. > > > > > > > > Yes, I explicitly said this in response to somebody for whom there was > > > > overwhelming evidence they were submitting AI slop, and that they'd > > > > need to > > > > build it back up again. > > > > > > > > It's precisely the issue as I see it. > > > > > > > > But others within the community disagreed with me, so it turned into a > > > > very > > > > long and draining discussion that I don't particularly wish to repeat. > > > > > > > > So we really need clarity on it being OK to do this (I remember saying > > > > this > > > > last year when I made an ultimately unsuccessful submission to the > > > > maintainer's summit about all this :) > > > > > > > > What matters overall is being able to _quickly_ dismiss AI slop so that > > > > asymmetry between LLM generation + maintainer time isn't exploited. > > > > > > > > And ultimately I think the trust model will end up being 'newcomes have > > > > 0, > > > > now build it up'. > > > > > > > > Which sucks but this issue is simply existential for open source. > > > > > > > > > > Has anybody tried throwing any of the obvious LLM slop submissions we > > > have seen into one of these LLM detector things? To be clear, I've never > > > tried those so I'm certainly no authority on if they even work reliably, > > > but if so I wonder if something like that is a potential solution for > > > elminating the worst cases.. > > > > > > I.e., suppose we had some Sashiko type LLM/bot whose job was mainly to > > > detect purely LLM generated content based on some minimum level of > > > confidence and reply with a loud and clear message to the thread. Maybe > > > that would be a clear enough signal to maintainers and reviewers that > > > something is not worth prioritizing for review.. Maybe also some "slop > > > detected" feedback would help disincentivize flinging slop onto the > > > lists. At the very least that could be something that is more easily > > > configured/enabled per-subsystem without having to use per-subsystem > > > commit tags. > > > > Yup I thought of this, have done this on series and they do detect it > > reliably. > > > > Interesting. > > > But then it becomes an arms race. People will get AI to try to defeat AI > > detection. So I'm not sure it's a safe road to go down. > > > > Yeah that's fair, but my thinking is the goal would be more to detect > slop content as opposed to just LLM usage. The trend of these > discussions has been that we generally don't care too much about LLM use > in general when it's used properly as a tool, but rather as you stated > earlier we want to be able to quickly dismiss slop to avoid wasting > maintainer and reviewer time. > > It seems like we're generally able to sniff out pure LLM generated > content in most cases. That suggests we should be able document some > common patterns that tend to describe slop such that an LLM bot could > detect and flag it. For example, "Slop bot has detected comments have > LLM prose and just repeat what the code does," "Slop bot has detected > unnecessary code volume and duplication," etc. etc.
Yep it might be helpful. But it turns out this is more contentious than you might think, and it might be a hard sell. > > So the idea with that would be that defeating the slop bot is the point. > Consider it a sort of informal/minimal goal before a submitter is > entitled to human review. But yeah, I guess it's still just a handwavy > theory that you'd be able to reliably disentagle detection of general > LLM code generation from something that more qualifies as LLM slop. Just > thinking out loud. Yeah tbh it'd not be perfect but I wouldn't mind if we did this. Some information > no information. > > Brian > > > > > > > Brian > > > > > > > Thanks, Lorenzo > > > Thanks, Lorenzo
