SUBMITTING_PATCHES 4.8 KB

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