Patches * send your patches to the mailing list or to the upstream maintainer (see the README file in project root directory). * 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 or git remote repository only. Downloading them from internet servers is a pain. See howto-pull-request.txt for remote repository instructions. * 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 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'. See also 'Patching process'. * if someone else wrote the patch, they should be credited (and blamed) for it. To communicate this, add a line: From: John Doe * 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 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 behavior is not unintentionally alterred. If you alter the behavior tell about it 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 in the submitted change. 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. * Mark resubmission with [PATCH v2]. Hint: git format-patch origin/master..yourbranch --subject-prefix='PATCH v2' * Use of remote repository for resubmission can be good idea. See also howto-pull-request.txt * 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.