1How to contribute patches to the PPP project. 2============================================= 3 4The PPP project source code is maintained in a Git repository, which 5is publicly available at 6 7git://git.ozlabs.org/~paulus/ppp.git 8 9and 10 11https://github.com/paulusmack/ppp.git 12 13The linux-ppp@vger.kernel.org mailing list is a suitable place to 14discuss issues relating to the PPP code and to post patches. 15 16Although there is a copy of the repository on github.com, the PPP 17project is not a "github project", in the sense that the development 18of the code does not depend on github infrastructure. In particular, 19patch descriptions should be understandable without reference to any 20github.com web page. Thus, patches or commits whose description 21consists only of something like "Closes #123" will be rejected. See 22below for the minimum standards for patch descriptions. 23 24There are two ways in which patches can be submitted for review: 25 261. Post the patch on the linux-ppp@vger.kernel.org mailing list. This 27 is my preferred way to receive patches, because it provides more 28 opportunity for other interested people to review the patches. 29 302. Create a pull request on github.com. However, please don't make 31 the mistake of creating a commit with a minimal commit message and 32 then explaining the rationale for the change in the pull request. 33 Put the rationale in the commit message. 34 35Requirements for patch/commit description 36----------------------------------------- 37 38The description on a patch, which becomes the commit message in the 39resulting commit, should describe the reason why the change is being 40made. If it fixes a bug, it should describe the bug in enough detail 41for the reader to understand why and how the change being made fixes 42the bug. If it adds a feature, it should describe the feature and how 43it might be used and why it would be desirable to have the feature. 44 45Normally the patch description should be a few paragraphs in length -- 46it can be longer for a really subtle bug or complex feature, or 47shorter for obvious or trivial changes such as fixing spelling 48mistakes. 49 50The first line of the commit message is the "headline", corresponding 51to the subject line of an emailed patch. If the patch is concerned 52with one particular area of the package, it is helpful to put that at 53the beginning, followed by a colon (':'), for example, "pppd: Fix bug 54in vslprintf". The remainder of the headline should be a sentence and 55should start with a capital letter. 56 57Note that as maintainer I will edit the headline or the commit message 58if necessary to make it clearer or to fix spelling or grammatical 59errors. For a github pull request I may cherry-pick the commits and 60modify their commit messages. 61 62References to information on web sites are permitted provided that the 63full URL is given, and that reference to the web site is not essential 64for understanding the change being made. For example, you can refer 65to a github issue provided that you also put the essential details of 66the issue in the commit message, and put the full URL for the issue, 67not just the issue number. 68 69Signoff 70------- 71 72In order to forestall possible (though unlikely) future legal 73problems, this project requires a "Signed-off-by" line on all 74non-trivial patches, with a real name (not just initials, and no 75pseudonyms). Signing off indicates that you certify that your patch 76meets the 'Developer's Certificate of Origin' below (taken from the 77DCO 1.1 in the Linux kernel source tree). 78 79Developer's Certificate of Origin 80--------------------------------- 81 82By making a contribution to this project, I certify that: 83 84 (a) The contribution was created in whole or in part by me and I 85 have the right to submit it under the open source license 86 indicated in the file; or 87 88 (b) The contribution is based upon previous work that, to the best 89 of my knowledge, is covered under an appropriate open source 90 license and I have the right under that license to submit that 91 work with modifications, whether created in whole or in part 92 by me, under the same open source license (unless I am 93 permitted to submit under a different license), as indicated 94 in the file; or 95 96 (c) The contribution was provided directly to me by some other 97 person who certified (a), (b) or (c) and I have not modified 98 it. 99 100 (d) I understand and agree that this project and the contribution 101 are public and that a record of the contribution (including all 102 personal information I submit with it, including my sign-off) is 103 maintained indefinitely and may be redistributed consistent with 104 this project or the open source license(s) involved. 105 106