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
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
Name
Contributing - instructions for contributing to the project
Synopsis
Email, patches, lint, style guide, and bug reports.
Description
Email
There's no mailing list. You can send an email to the maintainer:
To: Alejandro Colomar <alx@kernel.org>
Patches
If you know how to fix a problem in a file, send a patch in an email
(see above).
- The subject of the email should contain "[patch]" in the subject line.
- Write a suitable subject line. Make sure to mention the name(s) of
the file(s) being patched. Example:
[patch] stpecpy.c: stpecpy(): Accept NULL
- 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.
- Send patches in diff -u format, inline inside the email message. If
you're worried about your mailer breaking the patch, then send it
both inline and as an attachment. You may find it useful to employ
git-send-email(1) and git-format-patch(1).
- Send logically separate patches. For unrelated files, or for
logically-separate issues in the same page, send separate emails.
- Make patches against the latest version of the project. Use git(1)
for getting the latest version.
Lint
If you plan to patch a file, consider running the linters configured in
the build system, to make sure your change doesn't add new warnings.
However, you might still get warnings that are not your fault. To
minimize that, do the following steps:
(1) Lint first the entire project, so that make(1) knows that it only
needs to lint again files that you will touch.
$ make -ij lint >/dev/null 2>&1
(2) Touch the file that you'll edit, and run make(1) again, to see
which warnings you'll still see from that file that are not your
fault.
$ touch src/c/str/len/strlen.c # replace by the file you'll modify
$ make -k lint
(3) Apply your changes, and then run make(1) again. You can ignore
warnings that you saw in step (2), but if you see any new ones,
please fix them if you know how, or at least note them in your
patch email.
$ vi src/c/str/len/strlen.c # do your work
$ make -k lint
See <INSTALL> for a list of dependencies that this feature requires.
If you can't meet them all, you can selectively run certain linters.
Style guide
There's no style guide. I follow a mix of the coding styles for Linux,
Git, Google, Nginx, and a bit of my own. Just look at surrounding style.
Reporting bugs
Report bugs in email, as patches.
|
