github.com/dctrud/umoci@v0.4.3-0.20191016193643-05a1d37de015/CONTRIBUTING.md (about) 1 ## Contribution Guidelines ## 2 3 If you're reading this, you're likely interested in contributing to this 4 project. That's great! The intention of this document is to describe the basic 5 requirements and rules-of-thumb for contributions. 6 7 ### Security Issues ### 8 9 If you are reporting a security issue, do not create an issue or file a pull 10 request on GitHub. Instead, disclose the issue responsibly by sending an email 11 to <mailto:asarai@suse.de>. If you feel it is necessary you may also encrypt 12 your email with [Pretty Good Privacy (PGP)][pgp] using the PGP key [`5F36 C6C6 13 1B54 6012 4A75 F5A6 9E18 AA26 7DDB 8DB4`][pgp-key]. *In future, the above email 14 will be replaced with a mailing list as part of our ongoing effort to reduce 15 the bus factor of this project.* 16 17 [pgp]: https://en.wikipedia.org/wiki/Pretty_Good_Privacy 18 [pgp-key]: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x9E18AA267DDB8DB4 19 20 ### Issues ### 21 22 If you have found a bug in this project or have a question, first make sure 23 that the issue you are facing has not already been reported by another user. If 24 the issue you are facing has already been reported and you have more 25 information to provide, feel free to add a follow-up comment (but avoid adding 26 "me too" style comments as it distracts from discussion). If you couldn't find 27 an existing report for your issue, feel free to [open a new issue][issue-new]. 28 If you do not wish to use proprietary software to submit an issue, you may send 29 an email to <mailto:asarai@suse.de> and I will submit an issue on your behalf. 30 31 When reporting an issue, please provide the following information (to the best 32 of your ability) so we can debug your issue far more easily: 33 34 * The version of this project you are using. If you are not using the latest 35 version of this project, please try to reproduce your issue on the latest 36 version. 37 38 * A (short) description of what you are trying to accomplish so as to avoid the 39 [XY problem][xy-problem]. 40 41 * A minimal example of the bug with a contrast between what you expect to 42 happen versus what actually happened. 43 44 [issue-new]: https://github.com/openSUSE/umoci/issues/new 45 [xy-problem]: http://xyproblem.info/ 46 47 ### Submitting Changes ### 48 49 In order to submit a change, you may [create a pull request][pr-new]. If you 50 do not wish to use proprietary software to submit an pull request, you may send 51 an email to <mailto:asarai@suse.de> and I will submit a pull request on your 52 behalf. 53 54 All changes should be based off the latest commit of the master branch of this 55 project. In order for a change to be merged into this project, it must fulfil 56 all of the following requirements (note that many of these only apply for major 57 changes): 58 59 * All changes must pass the automated testing and continuous integration. This 60 means they must build successfully without errors, must not produce errors 61 from static analysis and must not break existing functionality. You can run 62 all of these tests on your local machine if you wish by reading through 63 `.travis.yml` and running the listed commands. 64 65 * All changes must be formatted using the Go style conventions, which ensures 66 that code remains consistent. You can automatically format your code in any 67 given `file.go` using `go fmt -s -w file.go`. 68 69 * Any significant changes (such as those that implement a feature or fix a bug) 70 must include an entry in the top-level [`CHANGELOG.md`][changelog] (see the 71 file for more details) that describes the change and links to the pull 72 request that implemented it (as well as issues that are being resolved). 73 74 * Any feature change or bug fix should include one or more corresponding test 75 cases to ensure that the code is operating as intended. Significant features 76 warrant the addition of significant numbers of both integration and unit 77 tests. 78 79 * Any feature change should include a corresponding change to the project 80 documentation describing the feature and how it should be used. 81 82 If you miss any of the above things, don't worry we'll remind you and provide 83 help if you need any. In addition to the above requirements, your code will be 84 reviewed by the maintainer(s) of this project, using the looks-good-to-me 85 system (LGTM). All patches must have the approval of at least two maintainers 86 that did not author a change before they are merged (the only exception to this 87 is related to the approval of security patches -- which must be approved in 88 private instead -- and cases where there are not enough maintainers to fulfil 89 this requirement). 90 91 Each commit should be self-contained and minimal (and should build and pass the 92 tests individually), and commit messages should follow the Linux kernel style 93 of commit messages. For more information see [§ 2 and 3 of 94 `submitting-patches.rst` from the Linux kernel source][lk-commit]. 95 96 In addition, all commits must include a `Signed-off-by:` line in their 97 description. This indicates that you certify [the following statement, known as 98 the Developer Certificate of Origin][dco]). You can automatically add this line 99 to your commits by using `git commit -s --amend`. 100 101 ``` 102 Developer Certificate of Origin 103 Version 1.1 104 105 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 106 1 Letterman Drive 107 Suite D4700 108 San Francisco, CA, 94129 109 110 Everyone is permitted to copy and distribute verbatim copies of this 111 license document, but changing it is not allowed. 112 113 114 Developer's Certificate of Origin 1.1 115 116 By making a contribution to this project, I certify that: 117 118 (a) The contribution was created in whole or in part by me and I 119 have the right to submit it under the open source license 120 indicated in the file; or 121 122 (b) The contribution is based upon previous work that, to the best 123 of my knowledge, is covered under an appropriate open source 124 license and I have the right under that license to submit that 125 work with modifications, whether created in whole or in part 126 by me, under the same open source license (unless I am 127 permitted to submit under a different license), as indicated 128 in the file; or 129 130 (c) The contribution was provided directly to me by some other 131 person who certified (a), (b) or (c) and I have not modified 132 it. 133 134 (d) I understand and agree that this project and the contribution 135 are public and that a record of the contribution (including all 136 personal information I submit with it, including my sign-off) is 137 maintained indefinitely and may be redistributed consistent with 138 this project or the open source license(s) involved. 139 ``` 140 141 [pr-new]: https://github.com/openSUSE/umoci/compare 142 [changelog]: /CHANGELOG.md 143 [lk-commit]: https://www.kernel.org/doc/Documentation/process/submitting-patches.rst 144 [dco]: https://developercertificate.org/