Re: [PATCH RFC] coding-assistants: simplify attribution

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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.

I can't quantifying which of the penalities will be higher, but I hope
(call me naive if you wish) that the vast majority of contributurs who
*know* we require disclosure to abide by that rule, even if it incurs a
penalty. After all, proponents for LLM usage claim such performance
improvements that a small penalty during review can't be that bad, right
? :-)

> We
> should drop the tag and instead think how we can empower maintainers to be
> able to use their own judgment and deprioritize dealing with what they
> perceive as LLM slop, without fearing consequences of not being properly
> responsible etc, and not rely on any non-enforceable tags for that.

-- 
Regards,

Laurent Pinchart