CONTRIBUTING.d/patches/sendmail: Add file documenting how to send patches

Signed-off-by: Alejandro Colomar <alx@kernel.org>

diff --git a/CONTRIBUTING.d/patches/patches b/CONTRIBUTING.d/patches/patches
index bccfb085fe535a2f38a001cbdda926e6663e7fe0..66fbb77bcc7c5df94c8145c7174fae6f9879e5aa 100644 (file)
--- a/CONTRIBUTING.d/patches/patches
+++ b/CONTRIBUTING.d/patches/patches
@@ -7,57 +7,9 @@ Description
 
        -  Configure git(1) for this project.  See <CONTRIBUTING.d/git>.
 
-       -  Follow the instructions for sending mail to the mailing list
-          from <CONTRIBUTING.d/mail>.  See also "Send the patches"
-          below.
-
-       The above is the minimum needed so that someone might respond to
-       your patch.  If you did that and someone does not respond within
-       a few days, then ping the email thread, "replying to all".  Make
-       sure to send it to the maintainers in addition to the mailing
-       list.
-
        To make your patch even more useful, please note the following
        points:
 
        -  Send logically separate patches.  For unrelated pages, or for
           logically-separate issues in the same page, send separate
           emails.
-
-   Send the patches
-       We recommend using git-send-email(1) to send the patches to the
-       mailing list.  For instructions on how to configure and use it,
-       see <https://git-send-email.io/>.  See also <CONTRIBUTING.d/git>.
-
-   Sign the patches with PGP
-       See <CONTRIBUTING.d/mail> for more details on signing your mail
-       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/*
-
-       <https://www.kernel.org/doc/Documentation/process/submitting-patches.rst>
-       <https://git-send-email.io/>
-       <https://neomutt.org/feature/cli-crypto>

diff --git a/CONTRIBUTING.d/patches/sendmail b/CONTRIBUTING.d/patches/sendmail
new file mode 100644 (file)
index 0000000..6ceb13b
--- /dev/null
+++ b/CONTRIBUTING.d/patches/sendmail
@@ -0,0 +1,51 @@
+Name
+       patches/sendmail - instructions for sending patches
+
+Description
+       Follow the instructions for sending mail to the mailing list
+       from <CONTRIBUTING.d/mail>.
+
+       Each patch should be sent in a separate email.  It is okay to
+       send patches as MIME attachments, but there should only be one
+       patch attached to each email.
+
+       We recommend using git-send-email(1) to send the patches to the
+       mailing list.  For instructions on how to configure and use it,
+       see <https://git-send-email.io/>.  See also
+       <CONTRIBUTING.d/git>.
+
+    Sign the email containing patches with PGP
+       See <CONTRIBUTING.d/mail> for more details on signing your mail
+       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 upstream cover letter.
+
+       3)      Send first the kernel/libc patch set, and then the
+               man-pages one, so that they have a consistent order.
+
+    Ping
+       If you sent any patches and someone does not respond within a
+       few days, then ping the email thread, "replying to all".
+
+See also
+       CONTRIBUTING.d/git
+       CONTRIBUTING.d/mail
+
+       <https://git-send-email.io/>
+       <https://neomutt.org/feature/cli-crypto>