]> git.proxmox.com Git - mirror_lxc.git/blame_incremental - CONTRIBUTING
Merge pull request #2450 from brauner/2018-07-05/use_mknod
[mirror_lxc.git] / CONTRIBUTING
... / ...
CommitLineData
1Contributing to this project
2----------------------------
3
4This project accepts contributions. In order to contribute, you should
5pay attention to a few things:
6
7 1 - your code must follow the coding style rules
8 2 - the format of the submission must Github pull requests
9 3 - your work must be signed
10
11
12Coding Style:
13-------------
14
15The coding style follows the Linux kernel coding style.
16
17The coding style is defined in the 'CodingStyle' file, available in
18the directory 'Documentation' of the Linux kernel source tree.
19
20It can be accessed online too:
21
22https://www.kernel.org/doc/html/v4.10/process/coding-style.html
23
24Submitting Modifications:
25-------------------------
26
27The contributions must be Github pull requests.
28
29Licensing for new files:
30------------------------
31
32LXC is made of files shipped under a few different licenses.
33
34Anything that ends up being part of the LXC library needs to be released
35under LGPLv2.1+ or a license compatible with it (though the latter will
36only be accepted for cases where the code originated elsewhere and was
37imported into LXC).
38
39Language bindings for the libraries need to be released under LGPLv2.1+.
40
41Anything else (non-libaries) needs to be Free Software and needs to be
42allowed to link with LGPLv2.1+ code (if needed). LXC upstream prefers
43LGPLv2.1+ or GPLv2 for those.
44
45When introducing a new file into the project, please make sure it has a
46copyright header making clear under which license it's being released
47and if it doesn't match the criteria described above, please explain
48your decision on the lxc-devel mailing-list when submitting your patch.
49
50Developer Certificate of Origin:
51--------------------------------
52
53To improve tracking of contributions to this project we will use a
54process modeled on the modified DCO 1.1 and use a "sign-off" procedure.
55
56The sign-off is a simple line at the end of the explanation for the
57patch, which certifies that you wrote it or otherwise have the right
58to pass it on as an open-source patch. The rules are pretty simple:
59if you can certify the below:
60
61By making a contribution to this project, I certify that:
62
63(a) The contribution was created in whole or in part by me and I have
64 the right to submit it under the open source license indicated in
65 the file; or
66
67(b) The contribution is based upon previous work that, to the best of
68 my knowledge, is covered under an appropriate open source License
69 and I have the right under that license to submit that work with
70 modifications, whether created in whole or in part by me, under
71 the same open source license (unless I am permitted to submit
72 under a different license), as indicated in the file; or
73
74(c) The contribution was provided directly to me by some other person
75 who certified (a), (b) or (c) and I have not modified it.
76
77(d) The contribution is made free of any other party's intellectual
78 property claims or rights.
79
80(e) I understand and agree that this project and the contribution are
81 public and that a record of the contribution (including all
82 personal information I submit with it, including my sign-off) is
83 maintained indefinitely and may be redistributed consistent with
84 this project or the open source license(s) involved.
85
86
87then you just add a line saying
88
89 Signed-off-by: Random J Developer <random@developer.org>
90
91You can do it by using option -s or --signoff when you commit
92
93 git commit --signoff ...
94
95using your real name (sorry, no pseudonyms or anonymous contributions.)
96
97In addition we support the following DCOs which maintainers can use to indicate
98that a patch is acceptable:
99
100 Acked-by: Random J Developer <random@developer.org>
101 Reviewed-by: Random J Developer <random@developer.org>
102
103If you are contributing as a group who is implementing a feature together such
104that it cannot be reasonably attributed to a single developer please use:
105
106 Co-developed-by: Random J Developer 1 <random_1@developer.org>
107 Co-developed-by: Random J Developer 2 <random_1@developer.org>