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. > > 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.
That would be my concern too. At this stage, I think it's better to make sure people know our expectations, and expect that the vast majority will understand it's a trust-based system where being caught willingly breaching trust will have a very high cost. Or have we reached a point where that doesn't work any more ? -- Regards, Laurent Pinchart
