diff options
| author | Alejandro Colomar <alx@kernel.org> | 2024-11-06 22:41:42 +0100 |
|---|---|---|
| committer | Alejandro Colomar <alx@kernel.org> | 2024-11-06 23:40:20 +0100 |
| commit | 999abcea29a50d99e8940525c88938e4839e7b4d (patch) | |
| tree | f5517cd6139382e3691e51fb4627004e55dbad03 | |
| parent | 4837a956d7e3f12497b69807aee93810159b3083 (diff) | |
| download | man-pages-999abcea29a50d99e8940525c88938e4839e7b4d.tar.gz | |
CONTRIBUTING.d/patches/sendmail: Add file documenting how to send patches
Signed-off-by: Alejandro Colomar <alx@kernel.org>
| -rw-r--r-- | CONTRIBUTING.d/patches/patches | 48 | ||||
| -rw-r--r-- | CONTRIBUTING.d/patches/sendmail | 51 |
2 files changed, 51 insertions, 48 deletions
diff --git a/CONTRIBUTING.d/patches/patches b/CONTRIBUTING.d/patches/patches index bccfb085fe..66fbb77bcc 100644 --- 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 index 0000000000..6ceb13b897 --- /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> |