Skip to content

Commit e3fd4d5

Browse files
committed
doc: add an initial SUBMITTING_PATCHES file
Signed-off-by: Paul Moore <[email protected]>
1 parent ab55783 commit e3fd4d5

File tree

1 file changed

+112
-0
lines changed

1 file changed

+112
-0
lines changed

SUBMITTING_PATCHES

Lines changed: 112 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,112 @@
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

Comments
 (0)