diff options
Diffstat (limited to 'Documentation/howto-contribute.txt')
| -rw-r--r-- | Documentation/howto-contribute.txt | 128 |
1 files changed, 128 insertions, 0 deletions
diff --git a/Documentation/howto-contribute.txt b/Documentation/howto-contribute.txt new file mode 100644 index 0000000..5df6389 --- /dev/null +++ b/Documentation/howto-contribute.txt @@ -0,0 +1,128 @@ +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. |