Knowing how AI generated patches were tested would be great help
when reviewing them. Explicitly ask people to describe discovery
and validation process they followed.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
Documentation/process/maintainer-netdev.rst | 28 +++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index ec7b9aa2877f..ffec42effe66 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -263,6 +263,34 @@ as a patch to the list with a commit message explaining the technical
problems with the reverted commit. Reverts should be used as a last resort,
when original change is completely wrong; incremental fixes are preferred.
+Bug fixes
+~~~~~~~~~
+
+All bug fixes must clearly state how the issue was discovered and validated,
+and how the fix was tested. This should be done in plain English, not with
+special tags or annotations.
+
+Example statements describing discovery:
+
+- discovered by a non-AI static analysis tool.
+- discovered by an AI code review agent.
+- discovered by manual code inspection.
+- triggered during code development.
+- triggered in CI testing.
+- observed on a machine in real use.
+
+If the issue was not observed in reality (e.g. it was caught by an AI tool
+or manual code inspection), the next sentence should describe the
+reproduction. The reproduction should state whether kernel modifications
+were necessary (e.g. inserting a delay to widen the race). The commit message
+must disclose if error injection or loading a special kernel module was used
+to trigger the issue. The reproduction steps should be included in the commit
+message if they are short (roughly 10 lines or fewer); longer reproducers can
+be posted online with a link included.
+
+The testing statement should explain whether the fix was tested against the
+reproducer and against kernel selftests.
+
Stable tree
~~~~~~~~~~~
--
2.55.0