|
| 1 | +How to Submit Patches to the libseccomp Project |
| 2 | +=============================================================================== |
| 3 | +https://github.com/seccomp/libseccomp-golang |
| 4 | + |
| 5 | +This document is intended to act as a guide to help you contribute to the |
| 6 | +libseccomp project. It is not perfect, and there will always be exceptions |
| 7 | +to the rules described here, but by following the instructions below you |
| 8 | +should have a much easier time getting your work merged with the upstream |
| 9 | +project. |
| 10 | + |
| 11 | +* Test Your Code |
| 12 | + |
| 13 | +There are two possible tests you can run to verify your code. The first test |
| 14 | +is used to check the formatting and coding style of your changes, you can run |
| 15 | +the test with the following command: |
| 16 | + |
| 17 | + # make check-syntax |
| 18 | + |
| 19 | +... if there are any problems with your changes a diff/patch will be shown |
| 20 | +which indicates the problems and how to fix them. |
| 21 | + |
| 22 | +The second possible test is used to ensure the sanity of your code changes |
| 23 | +and to test these changes against the included tests. You can run the test |
| 24 | +with the following command: |
| 25 | + |
| 26 | + # make check |
| 27 | + |
| 28 | +... if there are any faults or errors they will be displayed. |
| 29 | + |
| 30 | +* Generate the Patch(es) |
| 31 | + |
| 32 | +Depending on how you decided to work with the libseccomp code base and what |
| 33 | +tools you are using there are different ways to generate your patch(es). |
| 34 | +However, regardless of what tools you use, you should always generate your |
| 35 | +patches using the "unified" diff/patch format and the patches should always |
| 36 | +apply to the libseccomp source tree using the following command from the top |
| 37 | +directory of the libseccomp sources: |
| 38 | + |
| 39 | + # patch -p1 < changes.patch |
| 40 | + |
| 41 | +If you are not using git, stacked git (stgit), or some other tool which can |
| 42 | +generate patch files for you automatically, you may find the following command |
| 43 | +helpful in generating patches, where "libseccomp.orig/" is the unmodified |
| 44 | +source code directory and "libseccomp/" is the source code directory with your |
| 45 | +changes: |
| 46 | + |
| 47 | + # diff -purN libseccomp-golang.orig/ libseccomp-golang/ |
| 48 | + |
| 49 | +When in doubt please generate your patch and try applying it to an unmodified |
| 50 | +copy of the libseccomp sources; if it fails for you, it will fail for the rest |
| 51 | +of us. |
| 52 | + |
| 53 | +* Explain Your Work |
| 54 | + |
| 55 | +At the top of every patch you should include a description of the problem you |
| 56 | +are trying to solve, how you solved it, and why you chose the solution you |
| 57 | +implemented. If you are submitting a bug fix, it is also incredibly helpful |
| 58 | +if you can describe/include a reproducer for the problem in the description as |
| 59 | +well as instructions on how to test for the bug and verify that it has been |
| 60 | +fixed. |
| 61 | + |
| 62 | +* Sign Your Work |
| 63 | + |
| 64 | +The sign-off is a simple line at the end of the patch description, which |
| 65 | +certifies that you wrote it or otherwise have the right to pass it on as an |
| 66 | +open-source patch. The "Developer's Certificate of Origin" pledge is taken |
| 67 | +from the Linux Kernel and the rules are pretty simple: |
| 68 | + |
| 69 | + Developer's Certificate of Origin 1.1 |
| 70 | + |
| 71 | + By making a contribution to this project, I certify that: |
| 72 | + |
| 73 | + (a) The contribution was created in whole or in part by me and I |
| 74 | + have the right to submit it under the open source license |
| 75 | + indicated in the file; or |
| 76 | + |
| 77 | + (b) The contribution is based upon previous work that, to the best |
| 78 | + of my knowledge, is covered under an appropriate open source |
| 79 | + license and I have the right under that license to submit that |
| 80 | + work with modifications, whether created in whole or in part |
| 81 | + by me, under the same open source license (unless I am |
| 82 | + permitted to submit under a different license), as indicated |
| 83 | + in the file; or |
| 84 | + |
| 85 | + (c) The contribution was provided directly to me by some other |
| 86 | + person who certified (a), (b) or (c) and I have not modified |
| 87 | + it. |
| 88 | + |
| 89 | + (d) I understand and agree that this project and the contribution |
| 90 | + are public and that a record of the contribution (including all |
| 91 | + personal information I submit with it, including my sign-off) is |
| 92 | + maintained indefinitely and may be redistributed consistent with |
| 93 | + this project or the open source license(s) involved. |
| 94 | + |
| 95 | +... then you just add a line to the bottom of your patch description, with |
| 96 | +your real name, saying: |
| 97 | + |
| 98 | + Signed-off-by: Random J Developer < [email protected]> |
| 99 | + |
| 100 | +* Email Your Patch(es) |
| 101 | + |
| 102 | +Finally, you will need to email your patches to the mailing list so they can |
| 103 | +be reviewed and potentially merged into the main libseccomp-golang repository. |
| 104 | +When sending patches to the mailing list it is important to send your email in |
| 105 | +text form, no HTML mail please, and ensure that your email client does not |
| 106 | +mangle your patches. It should be possible to save your raw email to disk and |
| 107 | +apply it directly to the libseccomp source code; if that fails then you likely |
| 108 | +have a problem with your email client. When in doubt try a test first by |
| 109 | +sending yourself an email with your patch and attempting to apply the emailed |
| 110 | +patch to the libseccomp-golang repository; if it fails for you, it will fail |
| 111 | +for the rest of us trying to test your patch and include it in the main |
| 112 | +libseccomp-golang repository. |
0 commit comments