1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
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>
|
