linux-next: manual merge of the jc_docs tree with the char-misc.current tree

[Mark Brown]

Hi all,

Today's linux-next merge of the jc_docs tree got a conflict in:

  Documentation/process/coding-assistants.rst

between commit:

  3d7c44f73765d ("docs: coding-assistant: explain important steps when looking for bugs")

from the char-misc.current tree and commits:

  d699a5da10394 ("docs: link AI coding assistants and tool-generated content pages")
  816d9992d9ed4 ("coding-assistants: simplify attribution")

from the jc_docs tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc Documentation/process/coding-assistants.rst
index e71df7d28467e,e62c9577d91a2..0000000000000
--- a/Documentation/process/coding-assistants.rst
+++ b/Documentation/process/coding-assistants.rst
@@@ -56,41 -56,4 +56,41 @@@ Basic development tools (git, gcc, make
  
  Example::
  
-   Assisted-by: Claude:claude-3-opus coccinelle sparse
+   Assisted-by: LLM coccinelle sparse
 +
 +Procedure for finding and fixing bugs
 +=====================================
 +
 +When an AI assistant is used to find and fix bugs, it **MUST** follow at least
 +these steps:
 +
 +1. Before starting, read the whole process documentation listed above, as well
 +   as any other document mentioned in the request. Do not rely on isolated
 +   parts found by keyword search.
 +2. Note the commit ID and Locate a bug as instructed.
 +3. For any bug found that is not trivial, verify that it looks real by
 +   attempting to create a reproducer to demonstrate it. Lacking it may cause
 +   the report to be ignored, as many unverified bug reports sent to maintainers
 +   happen to be invalid. Stop here if it finally looks wrong.
 +4. Write a fix for the bug. This part is not optional: except in a few very
 +   rare cases, an AI assistant able to find a bug is able to fix it. Note that
 +   fixes written in the same session as used to find the bug will generally
 +   lead to better and more accurate fixes as the LLM's reasoning context
 +   remains present.
 +5. Build and verify that the fix works either using the reproducer or by
 +   re-running a complete analysis; drop any fix that doesn't work and try
 +   another one. The fix must not add build warnings and must pass the
 +   checkpatch.pl checks (see submitting-patches.rst).
 +6. Commit the working fix with a detailed message describing the problem, the
 +   solution and a Fixes tag. Do not add a Signed-off-by tag, and add an
 +   Assisted-by tag, as described above.
 +7. Identify the maintainers and lists using scripts/get_maintainer.pl.
 +   Documentation/process/security-bugs.rst shows how to do that.
 +8. Indicate what could not be done. If the fix could not be built or tested, or
 +   if no reproducer could be produced, say so explicitly: maintainers currently
 +   waste too much time analyzing unverified reports and untested fixes.
 +9. Read Documentation/process/threat-model.rst to determine whether the bug is
 +   a vulnerability or a regular bug, and leave the result to the reporter for
 +   review (the assistant must never send anything itself). Regular bugs are
 +   submitted as described in Documentation/process/submitting-patches.rst,
 +   vulnerabilities as described in Documentation/process/security-bugs.rst.