From 347904e33a8a1993316e57445a1ba8243cd947ce Mon Sep 17 00:00:00 2001 From: Paul Mackerras Date: Mon, 10 Jun 2019 17:58:07 +1000 Subject: [PATCH] Add Submitting-patches.md This adds a file that describes the standards expected for patches and pull requests. The standards are different from those for most projects on github.com and hence need to be spelled out. Signed-off-by: Paul Mackerras --- Submitting-patches.md | 105 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 Submitting-patches.md diff --git a/Submitting-patches.md b/Submitting-patches.md new file mode 100644 index 0000000..6bda0a2 --- /dev/null +++ b/Submitting-patches.md @@ -0,0 +1,105 @@ +How to contribute patches to the PPP project. +============================================= + +The PPP project source code is maintained in a Git repository, which +is publicly available at + +git://git.ozlabs.org/~paulus/ppp.git + +and + +https://github.com/paulusmack/ppp.git + +The linux-ppp@vger.kernel.org mailing list is a suitable place to +discuss issues relating to the PPP code and to post patches. + +Although there is a copy of the repository on github.com, the PPP +project is not a "github project", in the sense that the development +of the code does not depend on github infrastructure. In particular, +patch descriptions should be understandable without reference to any +github.com web page. Thus, patches or commits whose description +consists only of something like "Closes #123" will be rejected. See +below for the minimum standards for patch descriptions. + +There are two ways in which patches can be submitted for review: + +1. Post the patch on the linux-ppp@vger.kernel.org mailing list. This + is my preferred way to receive patches, because it provides more + opportunity for other interested people to review the patches. + +2. Create a pull request on github.com. However, please don't make + the mistake of creating a commit with a minimal commit message and + then explaining the rationale for the change in the pull request. + Put the rationale in the commit message. + +Requirements for patch/commit description +----------------------------------------- + +The description on a patch, which becomes the commit message in the +resulting commit, should describe the reason why the change is being +made. If it fixes a bug, it should describe the bug in enough detail +for the reader to understand why and how the change being made fixes +the bug. If it adds a feature, it should describe the feature and how +it might be used and why it would be desirable to have the feature. + +Normally the patch description should be a few paragraphs in length -- +it can be longer for a really subtle bug or complex feature, or +shorter for obvious or trivial changes such as fixing spelling +mistakes. + +The first line of the commit message is the "headline", corresponding +to the subject line of an emailed patch. If the patch is concerned +with one particular area of the package, it is helpful to put that at +the beginning, followed by a colon (':'), for example, "pppd: Fix bug +in vslprintf". The remainder of the headline should be a sentence and +should start with a capital letter. + +Note that as maintainer I will edit the headline or the commit message +if necessary to make it clearer or to fix spelling or grammatical +errors. For a github pull request I may cherry-pick the commits and +modify their commit messages. + +References to information on web sites are permitted provided that the +full URL is given, and that reference to the web site is not essential +for understanding the change being made. For example, you can refer +to a github issue provided that you also put the essential details of +the issue in the commit message, and put the full URL for the issue, +not just the issue number. + +Signoff +------- + +In order to forestall possible (though unlikely) future legal +problems, this project requires a "Signed-off-by" line on all +non-trivial patches, with a real name (not just initials, and no +pseudonyms). Signing off indicates that you certify that your patch +meets the 'Developer's Certificate of Origin' below (taken from the +DCO 1.1 in the Linux kernel source tree). + +Developer's Certificate of Origin +--------------------------------- + +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. + -- 2.39.2