The file contens are mostly from former README.devel.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Notes for util-linux developers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-AUTOTOOLS:
-
- * "./autogen.sh" generates all files needed to compile and install the code
- (run it after checkout from git)
-
- * "make distclean" removes all unnecessary files, but the code can still be
- recompiled with "./configure; make"
-
- * "make dist-gzip" (or -bzip2) creates a tarball that can be configured and
- compiled without running "./autogen.sh"
-
-
-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 [-X])
-
- * 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
-
-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
-
-
SCM (source code management):
git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git util-linux
--- /dev/null
+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.
Checkout:
git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git util-linux
+
NLS (PO TRANSLATIONS):
PO files are maintained by:
http://translationproject.org/domain/util-linux-ng.html
-NEUTRALITY:
-
- The stuff in util-linux should be rather distribution-neutral.
- No RPMs/DEBs/... are provided - get yours from your distributor.
-
VERSION SCHEMA:
projects / thirdparty / util-linux.git / commitdiff
