[sendemail]
sendmailcmd = neomutt -C -H - && true
- Patches
- If you know how to fix a problem in a manual page (if not, see
- "Reporting bugs" below), then send a patch in an email.
-
- - Follow the instructions for sending mail to the mailing list
- above.
-
- - The subject of the email should contain "[patch]" in the
- subject line.
-
- 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:
-
- - Write a suitable subject line. Make sure to mention the
- name(s) of the page(s) being patched. Example:
-
- [patch] shmop.2: Add "(void *)" cast to RETURN VALUE
-
- - Sign your patch with "Signed-off-by:". Read about the
- "Developer's Certificate of Origin" at
- <https://www.kernel.org/doc/Documentation/process/submitting-patches.rst>.
- When appropriate, other tags documented in that file, such as
- "Reported-by:", "Reviewed-by:", "Acked-by:", and
- "Suggested-by:" can be added to the patch. The man-pages
- project also uses a "Cowritten-by:" tag with the obvious
- meaning. Example:
-
- Signed-off-by: Alejandro Colomar <alx@kernel.org>
-
- - Describe how you obtained the information in your patch. For
- example, was it:
-
- - by reading (or writing) the relevant kernel or (g)libc
- source code? Please provide a pointer to the following
- code.
-
- - from a commit message in the kernel or (g)libc source code
- repository? Please provide a commit ID.
-
- - by writing a test program? Send it with the patch, but
- please make sure it's as simple as possible, and provide
- instructions on how to use it and/or a demo run.
-
- - from a standards document? Please name the standard, and
- quote the relevant text.
-
- - from other documentation? Please provide a pointer to that
- documentation.
-
- - from a mailing list or online forum? Please provide a URL
- if possible.
-
- - Send patches in diff -u format in an email patch. You may
- find it useful to employ git-send-email(1) and
- git-format-patch(1).
-
- - Where relevant, include source code comments that cite commit
- hashes for relevant kernel or glibc changes:
-
- .\" commit <40-character-git-hash>
-
- - For trivial patches, you can use subject tags:
-
- - ffix: Formatting fix.
- - tfix: Typo fix.
- - wfix: Minor wording fix.
- - srcfix: Change to manual page source that doesn't affect
- the output.
-
- Example:
-
- [patch] tcp.7: tfix
-
- - Send logically separate patches. For unrelated pages, or for
- logically-separate issues in the same page, send separate
- emails.
-
- - Make patches against the latest version of the manual page.
- Use git(1) for getting the latest version.
-
See also
CONTRIBUTING.d/bugs
CONTRIBUTING.d/external_pages
CONTRIBUTING.d/lint
+ CONTRIBUTING.d/patches
CONTRIBUTING.d/style
<https://www.kernel.org/doc/man-pages/linux-man-ml.html>
<https://www.kernel.org/doc/man-pages/missing_pages.html>
<https://www.kernel.org/doc/man-pages/code_of_conduct.html>
- <https://www.kernel.org/doc/Documentation/process/submitting-patches.rst>
--- /dev/null
+Name
+ Patches - instructions for contributing patches
+
+Description
+ If you know how to fix a problem in a manual page (if not, see
+ <CONTRIBUTING.d/bugs>), then send a patch in an email.
+
+ - Follow the instructions for sending mail to the mailing list
+ from <CONTRIBUTING.d/mail>.
+
+ - The subject of the email should contain "[patch]" in the
+ subject line.
+
+ 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:
+
+ - Write a suitable subject line. Make sure to mention the
+ name(s) of the page(s) being patched. Example:
+
+ [patch] shmop.2: Add "(void *)" cast to RETURN VALUE
+
+ - Sign your patch with "Signed-off-by:". Read about the
+ "Developer's Certificate of Origin" at
+ <https://www.kernel.org/doc/Documentation/process/submitting-patches.rst>.
+ When appropriate, other tags documented in that file, such as
+ "Reported-by:", "Reviewed-by:", "Acked-by:", and
+ "Suggested-by:" can be added to the patch. The man-pages
+ project also uses a "Cowritten-by:" tag with the obvious
+ meaning. Example:
+
+ Signed-off-by: Alejandro Colomar <alx@kernel.org>
+
+ - Describe how you obtained the information in your patch. For
+ example, was it:
+
+ - by reading (or writing) the relevant kernel or (g)libc
+ source code? Please provide a pointer to the following
+ code.
+
+ - from a commit message in the kernel or (g)libc source code
+ repository? Please provide a commit ID.
+
+ - by writing a test program? Send it with the patch, but
+ please make sure it's as simple as possible, and provide
+ instructions on how to use it and/or a demo run.
+
+ - from a standards document? Please name the standard, and
+ quote the relevant text.
+
+ - from other documentation? Please provide a pointer to that
+ documentation.
+
+ - from a mailing list or online forum? Please provide a URL
+ if possible.
+
+ - Send patches in diff -u format in an email patch. You may
+ find it useful to employ git-send-email(1) and
+ git-format-patch(1).
+
+ - Where relevant, include source code comments that cite commit
+ hashes for relevant kernel or glibc changes:
+
+ .\" commit <40-character-git-hash>
+
+ - For trivial patches, you can use subject tags:
+
+ - ffix: Formatting fix.
+ - tfix: Typo fix.
+ - wfix: Minor wording fix.
+ - srcfix: Change to manual page source that doesn't affect
+ the output.
+
+ Example:
+
+ [patch] tcp.7: tfix
+
+ - Send logically separate patches. For unrelated pages, or for
+ logically-separate issues in the same page, send separate
+ emails.
+
+ - Make patches against the latest version of the manual page.
+ Use git(1) for getting the latest version.
+
+See also
+ CONTRIBUTING
+ CONTRIBUTING.d/*
+
+ <https://www.kernel.org/doc/Documentation/process/submitting-patches.rst>
projects / thirdparty / man-pages.git / commitdiff
