> Op 07-07-2026 11:20 CEST schreef Lorenzo Stoakes <[email protected]>: > > > On Fri, Jul 03, 2026 at 08:22:20PM +0200, David Hildenbrand (Arm) wrote: > > On 7/3/26 18:32, Laurent Pinchart wrote: > > > On Fri, Jul 03, 2026 at 02:12:40PM +0100, Lorenzo Stoakes wrote: > > >> On Fri, Jul 03, 2026 at 09:05:58AM +0200, David Hildenbrand (Arm) wrote: > > >> > > >> I personally think 1-2 are the only relevant cases. > > >> > > >>> > > >>> Yes, I raised something similar as reply to Christian's RFC [1], where > > >>> I said > > >>> that for me the information *how* it was used is much more important: > > >>> > > >>> " > > >>> Assisted-by: LLM # translate commit message > > >>> Assisted-by: LLM # generate some test cases > > >>> Assisted-by: LLM # cleanup logic > > >>> Assisted-by: LLM # everything and I have no clue what any in here does > > >>> " > > >> > > >> Yup, and we don't need complicated rules for that just 'document what > > >> you used > > >> it for and give a sense of how much'. > > >> > > >> It's fuzzy but useful. > > >> > > >>> > > >>> That tag is it stands is pretty useless, really. > > >> > > >> Not to go over it all again but I disagree, even as it stands, it allows > > >> us to > > >> engage in conversation about the LLM usage if admitted, and to point > > >> those who > > >> are misbehaving at the rules if not. > > >> > > >> And it is a clear way to get the boolean 'is this person saying they > > >> used an > > >> LLM'. > > >> > > >> But I agree with you it'd be MUCH more useful if we did the above. > > >> > > >> I wonder if we could get consensus on adding a section to the doc saying > > >> that > > >> it'd be _useful_ to add a comment explaining _what_ you did, and > > >> explaining the > > >> concept with some examples? > > > > > > I'd support a patch that replaces > > > > > > Assisted-by: Claude:claude-3-opus coccinelle sparse > > > > > > with > > > > > > Assisted-by: LLM # generate some test cases > > > > > > and rewrites the Attribution section of > > > Documentation/process/coding-assistants.rst accordingly. > > > > > > I think most people in this mail thread have expressed that how > > > generative AI was used is the most important information, and several > > > people (including myself) have expressed a desire to stop the free > > > advertising. Unless I missed something, I don't think anyone has > > > expressed an interest in keeping the agent name and model. > > > > Yes, that's something I would enjoy seeing. Who reading along has a problem > > with > > that? (assuming that the tag must stay) > > I think the silence suggests nobody :) > > What we could do is send a patch to simply add a section on adding a comment > explaining _what_ used an LLM and strongly suggesting it would be helpful to > do > so. > > That should hopefully be uncontroversial, then later (or alongside that?) we > could submit an RFC for making the language move to 'you MUST do this', as > that > will probably be the more controversial bit. > > I don't see any reason why we can't just send the softer version right away. > > > > > -- > > Cheers, > > > > David > > Cheers, Lorenzo
I haven't really seen anyone opposed the following I wrote earlier: - it's more relevant to know how an LLM was used than that it was used (and the tag is just a quick indication of this) - advertising for particular corporations does not really serve any purpose to the community, so just say "LLM" - the tags may be used to prevent arguing - the requirement to be open about LLM use (whether by tags or whatever) makes it easier for maintainers (if they feel the need) to de-prioritize patches by someone unwilling to abide by these rules whenever the maintainer perceives or suspects prior undeclared LLM use. This prevents an asymmetrical situation of LLM slop being produced much faster that what can be reviewed. Perhaps the last point is more controversial. I would really like to adept the systemd policy text.[1] If I have time later today I'll try to write something up... although maybe it is too ambitious :) [1]: https://lore.kernel.org/linux-fsdevel/20260702-bahnen-ertappen-verspannungen-0eaaf1e3f5af@brauner/
