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
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
Patches
* send your patches to the mailing list or to the upstream maintainer
(see the AUTHORS and README files)
* diff -u
* don't include generated (autotools) stuff to your patches (hint:
use git clean -Xd)
* neutrality; The stuff in util-linux should be rather
distribution-neutral. No RPMs/DEBs/... are provided - get yours
from your distributor.
* patches are delivered via email only. Downloading them from
internet servers is a pain.
* one patch per email, with the changelog in the body of the email.
* many small patches are favoured over one big. Break down is done on
basis of logical functionality; for example #endif mark ups,
compiler warning and exit codes fixes all should be individual
small patches.
* Subject: [PATCH] subsystem: description
* if someone else wrote the patch, they should be credited (and
blamed) for it. To communicate this, add a line:
From: John Doe <jdoe@wherever.com>
* add a Signed-off-by line (hint: use "git commit -s")
The sign-off is a simple line at the end of the explanation for the
patch, which certifies that you wrote it or otherwise have the
right to pass it on as a open-source patch. The rules are pretty
simple: if you can certify the below:
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including
all personal information I submit with it, including my
sign-off) is maintained indefinitely and may be redistributed
consistent with this project or the open source license(s)
involved.
then you just add a line saying
Signed-off-by: Random J Developer <random@developer.example.org>
using your real name (sorry, no pseudonyms or anonymous
contributions.)
Before sending a patch
* make sure that after patching source files will compile without
errors.
* test that previously existed program behavior is not
unintentionally alterred. If you alter the behavior tell about in
commit message.
Coding style
* the preferred coding style is based on the linux kernel
Documentation/CodingStyle. For more details see:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/CodingStyle
* Use `FIXME:' and a good description if want to inform others
something is not quite right, and you are unwilling to fix the
issue.
Patching process
* Tell in mail list when you are going to work with some particular
piece of code for long time. This helps other to avoid massive
merge conflicts. Small or quick work does not need to be
announced.
* Submit only changes that you think are ready to merge. If you only
want change review tell your intention clearly in change cover
letter, and/or in each patch subject to review-only.
* When getting comments align the changes with them. Resubmission
without changes is as good as ignoring advice, and is neither
recommended nor polite.
* Resubmission can be partial or complete. If only few alterations
are needed here and there resubmit particular patches. When
comments cause greater effect resubmit everything again.
* All patch submissions, big or small, are either commented, reject,
or merge. When maintainer rejects a patch (series) it is pointless
to resubmit.
Various notes
* The util-linux does not use kernel headers for file system super
blocks structures.
* Patches relying on features that are not in Linus' tree
are not accepted.
* Do not use `else' after non-returning functions. For
example
if (this)
err(EXIT_FAIL, "this failed");
else
err(EXIT_FAIL, "that failed");
is wrong and should be wrote
if (this)
err(EXIT_FAIL, "this failed");
err(EXIT_FAIL, "that failed");
* When you use if shortshort hand make sure it is not wrapped to
multiple lines. In case the shorthand does not look good on one
line use normal "if () else" syntax.
Standards compliancy
Some of the commands maintained in this package have Open Group
requirements. These commands are;
cal
col
ipcrm
ipcs
kill
line
logger
mesg
more
newgrp
pg
renice
If you change these tools please make sure a change does not
conflict with the latest standard. For example it is
recommendable not to add short command line options before they
are part of standard. Introducing new long options is
acceptable.
The Single UNIX(TM) Specification, Version 2
Copyright (C) 1997 The Open Group
http://pubs.opengroup.org/onlinepubs/7908799/xcuix.html
IRC channel
* We have a new #util-linux IRC channel at freenode.net.
irc://chat.freenode.net/util-linux
the channel is for developers or upstream maintainers. User
support is recommended to go to distribution channels or
forums.
|