blob: 5df6389abfb2d336b0d4e36c906301e83e8e1b5f (
plain) (
tree)
|
|
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.)
* for more details see: The perfect patch
http://userweb.kernel.org/~akpm/stuff/tpp.txt
Before sending a patch
* make sure that after patching source files will compile without
errors.
* test that previously existed program behaviour is not
unintentionally alterred. If you alter the behaviour 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/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=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.
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.
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.
|
