CONTRIBUTING.d/patches: Documentation patches should be sent alongside the features

Link: <https://lwn.net/Articles/989380/>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Günther Noack <gnoack@google.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>

diff --git a/CONTRIBUTING.d/patches b/CONTRIBUTING.d/patches
index fedb163d33382a43f9230da4354eac73903e8c41..5a45b9ca8dfd66a802cb0c68b1f7d5224fb8ad37 100644 (file)
--- a/CONTRIBUTING.d/patches
+++ b/CONTRIBUTING.d/patches
@@ -131,6 +131,26 @@ Description
        to the list.  See also <CONTRIBUTING.d/git> for instructions for
        configuring git-send-email(1) to use neomutt(1) as a driver.
 
+   New kernel/libc features
+       If you write a new kernel or libc feature, you should document it
+       in the same patch set that adds the feature, including any
+       patches to the manual pages.  The entire patch set consisting of
+       both the feature and its manual page should be sent to all
+       recipients for a better review process.  That can be done with
+       the following procedure:
+
+       1)  Generate the kernel or libc patch set, with a cover letter,
+           and using --thread in git-format-patch(1) (as specified in
+           our ./CONTRIBUTING.d/git).  This will generate a Message-ID
+           header field in the cover letter.
+
+       2)  Generate the man-pages patch set using
+           --in-reply-to="<message-id>", where <message-id> is the value
+           of the header field of the cover letter.
+
+       3)  Send first the kernel/libc patch set, and then the man-pages
+           one, so that they have a consistent order.
+
 See also
        CONTRIBUTING
        CONTRIBUTING.d/*