2011-08-12 13:47:42 -05:00
|
|
|
Patches
|
|
|
|
|
|
|
|
* send your patches to the mailing list or to the upstream maintainer
|
2015-01-07 13:25:38 -06:00
|
|
|
(see the README file in project root directory).
|
2011-08-12 13:47:42 -05:00
|
|
|
|
|
|
|
* 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.
|
|
|
|
|
2015-01-07 13:25:39 -06:00
|
|
|
* patches are delivered via email or git remote repository only.
|
|
|
|
Downloading them from internet servers is a pain. See
|
|
|
|
howto-pull-request.txt for remote repository instructions.
|
2011-08-12 13:47:42 -05:00
|
|
|
|
|
|
|
* one patch per email, with the changelog in the body of the email.
|
|
|
|
|
2015-01-07 13:25:38 -06:00
|
|
|
* mail attachments are difficult. Tip:
|
|
|
|
git send-email --to util-linux@vger.kernel.org origin/master..yourbranch
|
|
|
|
|
2011-08-12 13:47:42 -05:00
|
|
|
* 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.
|
|
|
|
|
2015-01-07 13:25:38 -06:00
|
|
|
* 'Subject: [PATCH] subsystem: description'. See also 'Patching
|
|
|
|
process'.
|
2011-08-12 13:47:42 -05:00
|
|
|
|
|
|
|
* 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.
|
|
|
|
|
2014-06-06 02:49:35 -05:00
|
|
|
* test that previously existed program behavior is not
|
2015-01-07 13:25:38 -06:00
|
|
|
unintentionally alterred. If you alter the behavior tell about
|
|
|
|
it in commit message.
|
2011-08-12 13:47:42 -05:00
|
|
|
|
|
|
|
Coding style
|
|
|
|
|
|
|
|
* the preferred coding style is based on the linux kernel
|
|
|
|
Documentation/CodingStyle. For more details see:
|
|
|
|
|
2013-11-10 14:06:10 -06:00
|
|
|
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/CodingStyle
|
2011-08-12 13:47:42 -05:00
|
|
|
|
|
|
|
* Use `FIXME:' and a good description if want to inform others
|
|
|
|
something is not quite right, and you are unwilling to fix the
|
2015-01-07 13:25:38 -06:00
|
|
|
issue in the submitted change.
|
2011-08-25 14:01:01 -05:00
|
|
|
|
2013-11-10 14:06:09 -06:00
|
|
|
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.
|
|
|
|
|
2015-01-07 13:25:38 -06:00
|
|
|
* Mark resubmission with [PATCH v2]. Hint:
|
|
|
|
git format-patch origin/master..yourbranch --subject-prefix='PATCH v2'
|
|
|
|
|
2015-01-07 13:25:39 -06:00
|
|
|
* Use of remote repository for resubmission can be good idea.
|
|
|
|
See also howto-pull-request.txt
|
|
|
|
|
2013-11-10 14:06:09 -06:00
|
|
|
* All patch submissions, big or small, are either commented, reject,
|
|
|
|
or merge. When maintainer rejects a patch (series) it is pointless
|
|
|
|
to resubmit.
|
|
|
|
|
2011-08-25 14:01:01 -05:00
|
|
|
Various notes
|
|
|
|
|
|
|
|
* The util-linux does not use kernel headers for file system super
|
|
|
|
blocks structures.
|
2011-08-27 14:46:36 -05:00
|
|
|
|
|
|
|
* Patches relying on features that are not in Linus' tree
|
|
|
|
are not accepted.
|
2011-09-17 07:35:15 -05:00
|
|
|
|
|
|
|
* 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.
|
2012-07-25 14:15:45 -05:00
|
|
|
|
2012-10-23 14:14:53 -05:00
|
|
|
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
|
|
|
|
|
2012-07-25 14:15:45 -05:00
|
|
|
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.
|