Re: [RFC PATCH] docs: submitting-patches: (AI?) Tool disclosure tag

[Sasha Levin <sashal@kernel.org>]

On Thu, Jul 24, 2025 at 04:54:11PM -0700, Kees Cook wrote:
>On Thu, Jul 24, 2025 at 07:45:56PM -0400, Steven Rostedt wrote:
>> My thought is to treat AI as another developer. If a developer helps you
>> like the AI is helping you, would you give that developer credit for that
>> work? If so, then you should also give credit to the tooling that's helping
>> you.
>>
>> I suggested adding a new tag to note any tool that has done non-trivial
>> work to produce the patch where you give it credit if it has helped you as
>> much as another developer that you would give credit to.
>
>We've got tags to choose from already in that case:
>
>Suggested-by: LLM
>
>or
>
>Co-developed-by: LLM <not@human.with.legal.standing>
>Signed-off-by: LLM <not@human.with.legal.standing>
>
>The latter seems ... not good, as it implies DCO SoB from a thing that
>can't and hasn't acknowledged the DCO.

In my mind, "any tool" would also be something like gcc giving you a
"non-trivial" error (think something like a buffer overflow warning that
could have been a security issue).

In that case, should we encode the entire toolchain used for developing
a patch?

Maybe...

Some sort of semi-standardized shorthand notation of the tooling used to
develop a patch could be interesting not just for plain disclosure, but
also to be able to trace back issues with patches ("oh! the author
didn't see a warning because they use gcc 13 while the warning was added
in gcc 14!").

Signed-off-by: John Doe <jd@example.com> # gcc:14.1;ccache:1.2;sparse:4.7;claude-code:0.5

This way some of it could be automated via git hooks and we can recommend
a relevant string to add with checkpatch.

-- 
Thanks,
Sasha