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.)

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/cgit/linux/kernel/git/torvalds/linux.git/plain/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.

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.

	* All patch submissions, big or small, are either commented, reject,
	  or merge.  When maintainer rejects a patch (series) it is pointless
	  to resubmit.

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.

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

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.