ericonr
/
util-linux
mirror of https://github.com/ericonr/util-linux.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

docs: small improvements to howto-contribute.txt 

Signed-off-by: Sami Kerola <kerolasa@iki.fi>
This commit is contained in:
Sami Kerola 2015-01-06 20:25:16 +00:00
parent 8501d9befe
commit 7f9916c21e
1 changed files with 12 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
Documentation/howto-contribute.txt
View File

@ -1,9 +1,7 @@
Patches Patches
* send your patches to the mailing list or to the upstream maintainer * send your patches to the mailing list or to the upstream maintainer
(see the AUTHORS and README files) (see the README file in project root directory).
* diff -u
* don't include generated (autotools) stuff to your patches (hint: * don't include generated (autotools) stuff to your patches (hint:
use git clean -Xd) use git clean -Xd)
@ -17,12 +15,16 @@ Patches
* one patch per email, with the changelog in the body of the email. * one patch per email, with the changelog in the body of the email.
* mail attachments are difficult. Tip:
git send-email --to util-linux@vger.kernel.org origin/master..yourbranch
* many small patches are favoured over one big. Break down is done on * many small patches are favoured over one big. Break down is done on
basis of logical functionality; for example #endif mark ups, basis of logical functionality; for example #endif mark ups,
compiler warning and exit codes fixes all should be individual compiler warning and exit codes fixes all should be individual
small patches. small patches.
* Subject: [PATCH] subsystem: description * 'Subject: [PATCH] subsystem: description'. See also 'Patching
process'.
* if someone else wrote the patch, they should be credited (and * if someone else wrote the patch, they should be credited (and
blamed) for it. To communicate this, add a line: blamed) for it. To communicate this, add a line:
@ -74,8 +76,8 @@ Before sending a patch
errors. errors.
* test that previously existed program behavior is not * test that previously existed program behavior is not
unintentionally alterred. If you alter the behavior tell about in unintentionally alterred. If you alter the behavior tell about
commit message. it in commit message.
Coding style Coding style
@ -86,7 +88,7 @@ Coding style
* Use `FIXME:' and a good description if want to inform others * Use `FIXME:' and a good description if want to inform others
something is not quite right, and you are unwilling to fix the something is not quite right, and you are unwilling to fix the
issue. issue in the submitted change.
Patching process Patching process
@ -107,6 +109,9 @@ Patching process
are needed here and there resubmit particular patches. When are needed here and there resubmit particular patches. When
comments cause greater effect resubmit everything again. comments cause greater effect resubmit everything again.
* Mark resubmission with [PATCH v2]. Hint:
git format-patch origin/master..yourbranch --subject-prefix='PATCH v2'
* All patch submissions, big or small, are either commented, reject, * All patch submissions, big or small, are either commented, reject,
or merge. When maintainer rejects a patch (series) it is pointless or merge. When maintainer rejects a patch (series) it is pointless
to resubmit. to resubmit.