From: Paul Moore <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
---
Makefile.am | 2 -
SUBMITTING_PATCHES | 123 -------------------------------------------------
SUBMITTING_PATCHES.md | 122 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 123 insertions(+), 124 deletions(-)
delete mode 100644 SUBMITTING_PATCHES
create mode 100644 SUBMITTING_PATCHES.md
diff --git a/Makefile.am b/Makefile.am
index 91ba36eb..29ee2ec1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -22,7 +22,7 @@ SUBDIRS = include src tools tests doc
pkgconfdir = ${libdir}/pkgconfig
pkgconf_DATA = libseccomp.pc
-EXTRA_DIST = CHANGELOG CREDITS LICENSE README.md SUBMITTING_PATCHES
+EXTRA_DIST = CHANGELOG CREDITS LICENSE README.md SUBMITTING_PATCHES.md
# support silent builds
AM_MAKEFLAGS_0 = --quiet --no-print-directory
diff --git a/SUBMITTING_PATCHES b/SUBMITTING_PATCHES
deleted file mode 100644
index 698ced82..00000000
--- a/SUBMITTING_PATCHES
+++ /dev/null
@@ -1,123 +0,0 @@
-How to Submit Patches to the libseccomp Project
-===============================================================================
-https://github.com/seccomp/libseccomp
-
-This document is intended to act as a guide to help you contribute to the
-libseccomp project. It is not perfect, and there will always be exceptions
-to the rules described here, but by following the instructions below you
-should have a much easier time getting your work merged with the upstream
-project.
-
-* Test Your Code
-
-There are three possible tests you can run to verify your code. The first
-test is used to check the formatting and coding style of your changes, you
-can run the test with the following command:
-
- # make check-syntax
-
-... if there are any problems with your changes a diff/patch will be shown
-which indicates the problems and how to fix them.
-
-The second possible test is used to ensure that the different internal syscall
-tables are consistent and to test your changes against the automated test
-suite. You can run the test with the following command:
-
- # make check
-
-... if there are any faults or errors they will be displayed; beware that the
-tests can run for some time and produce a lot of output.
-
-The third possible test is used to validate libseccomp against a live, running
-system using some simple regression tests. After ensuring that your system
-supports seccomp filters you can run the live tests with the following
-command:
-
- # make check-build
- # cd tests
- # ./regression -T live
-
-... if there are any faults or errors they will be displayed.
-
-* Generate the Patch(es)
-
-Depending on how you decided to work with the libseccomp code base and what
-tools you are using there are different ways to generate your patch(es).
-However, regardless of what tools you use, you should always generate your
-patches using the "unified" diff/patch format and the patches should always
-apply to the libseccomp source tree using the following command from the top
-directory of the libseccomp sources:
-
- # patch -p1 < changes.patch
-
-If you are not using git, stacked git (stgit), or some other tool which can
-generate patch files for you automatically, you may find the following command
-helpful in generating patches, where "libseccomp.orig/" is the unmodified
-source code directory and "libseccomp/" is the source code directory with your
-changes:
-
- # diff -purN libseccomp.orig/ libseccomp/
-
-When in doubt please generate your patch and try applying it to an unmodified
-copy of the libseccomp sources; if it fails for you, it will fail for the rest
-of us.
-
-* Explain Your Work
-
-At the top of every patch you should include a description of the problem you
-are trying to solve, how you solved it, and why you chose the solution you
-implemented. If you are submitting a bug fix, it is also incredibly helpful
-if you can describe/include a reproducer for the problem in the description as
-well as instructions on how to test for the bug and verify that it has been
-fixed.
-
-* Sign Your Work
-
-The sign-off is a simple line at the end of the patch description, which
-certifies that you wrote it or otherwise have the right to pass it on as an
-open-source patch. The "Developer's Certificate of Origin" pledge is taken
-from the Linux Kernel and the rules are pretty simple:
-
- Developer's Certificate of Origin 1.1
-
- 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.
-
-... then you just add a line to the bottom of your patch description, with
-your real name, saying:
-
- Signed-off-by: Random J Developer <[email protected]>
-
-* Email Your Patch(es)
-
-Finally, you will need to email your patches to the mailing list so they can
-be reviewed and potentially merged into the main libseccomp repository. When
-sending patches to the mailing list it is important to send your email in text
-form, no HTML mail please, and ensure that your email client does not mangle
-your patches. It should be possible to save your raw email to disk and apply
-it directly to the libseccomp source code; if that fails then you likely have
-a problem with your email client. When in doubt try a test first by sending
-yourself an email with your patch and attempting to apply the emailed patch to
-the libseccomp repository; if it fails for you, it will fail for the rest of
-us trying to test your patch and include it in the main libseccomp repository.
diff --git a/SUBMITTING_PATCHES.md b/SUBMITTING_PATCHES.md
new file mode 100644
index 00000000..61170ea2
--- /dev/null
+++ b/SUBMITTING_PATCHES.md
@@ -0,0 +1,122 @@
+How to Submit Patches to the libseccomp Project
+===============================================================================
+https://github.com/seccomp/libseccomp
+
+This document is intended to act as a guide to help you contribute to the
+libseccomp project. It is not perfect, and there will always be exceptions
+to the rules described here, but by following the instructions below you
+should have a much easier time getting your work merged with the upstream
+project.
+
+## Test Your Code
+
+There are three possible tests you can run to verify your code. The first
+test is used to check the formatting and coding style of your changes, you
+can run the test with the following command:
+
+ # make check-syntax
+
+... if there are any problems with your changes a diff/patch will be shown
+which indicates the problems and how to fix them.
+
+The second possible test is used to ensure that the different internal syscall
+tables are consistent and to test your changes against the automated test
+suite. You can run the test with the following command:
+
+ # make check
+
+... if there are any faults or errors they will be displayed; beware that the
+tests can run for some time and produce a lot of output.
+
+The third possible test is used to validate libseccomp against a live, running
+system using some simple regression tests. After ensuring that your system
+supports seccomp filters you can run the live tests with the following
+command:
+
+ # make check-build
+ # (cd tests; ./regression -T live)
+
+... if there are any faults or errors they will be displayed.
+
+## Generate the Patch(es)
+
+Depending on how you decided to work with the libseccomp code base and what
+tools you are using there are different ways to generate your patch(es).
+However, regardless of what tools you use, you should always generate your
+patches using the "unified" diff/patch format and the patches should always
+apply to the libseccomp source tree using the following command from the top
+directory of the libseccomp sources:
+
+ # patch -p1 < changes.patch
+
+If you are not using git, stacked git (stgit), or some other tool which can
+generate patch files for you automatically, you may find the following command
+helpful in generating patches, where "libseccomp.orig/" is the unmodified
+source code directory and "libseccomp/" is the source code directory with your
+changes:
+
+ # diff -purN libseccomp.orig/ libseccomp/
+
+When in doubt please generate your patch and try applying it to an unmodified
+copy of the libseccomp sources; if it fails for you, it will fail for the rest
+of us.
+
+## Explain Your Work
+
+At the top of every patch you should include a description of the problem you
+are trying to solve, how you solved it, and why you chose the solution you
+implemented. If you are submitting a bug fix, it is also incredibly helpful
+if you can describe/include a reproducer for the problem in the description as
+well as instructions on how to test for the bug and verify that it has been
+fixed.
+
+## Sign Your Work
+
+The sign-off is a simple line at the end of the patch description, which
+certifies that you wrote it or otherwise have the right to pass it on as an
+open-source patch. The "Developer's Certificate of Origin" pledge is taken
+from the Linux Kernel and the rules are pretty simple:
+
+ Developer's Certificate of Origin 1.1
+
+ 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.
+
+... then you just add a line to the bottom of your patch description, with
+your real name, saying:
+
+ Signed-off-by: Random J Developer <[email protected]>
+
+## Email Your Patch(es)
+
+Finally, you will need to email your patches to the mailing list so they can
+be reviewed and potentially merged into the main libseccomp repository. When
+sending patches to the mailing list it is important to send your email in text
+form, no HTML mail please, and ensure that your email client does not mangle
+your patches. It should be possible to save your raw email to disk and apply
+it directly to the libseccomp source code; if that fails then you likely have
+a problem with your email client. When in doubt try a test first by sending
+yourself an email with your patch and attempting to apply the emailed patch to
+the libseccomp repository; if it fails for you, it will fail for the rest of
+us trying to test your patch and include it in the main libseccomp repository.
--
You received this message because you are subscribed to the Google Groups
"libseccomp" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
