]>
Commit | Line | Data |
---|---|---|
f2b9c257 RS |
1 | HOW TO CONTRIBUTE TO PATCHES OpenSSL |
2 | ------------------------------------ | |
eb05f173 | 3 | |
f2b9c257 RS |
4 | (Please visit https://openssl.org/community/getting-started.html for |
5 | other ideas about how to contribute.) | |
eb05f173 | 6 | |
f2b9c257 RS |
7 | Development is coordinated on the openssl-dev mailing list (see the |
8 | above link or http://mta.openssl.org for information on subscribing). | |
eb05f173 | 9 | If you are unsure as to whether a feature will be useful for the general |
f2b9c257 RS |
10 | OpenSSL community you might want to discuss it on the openssl-dev mailing |
11 | list first. Someone may be already working on the same thing or there | |
12 | may be a good reason as to why that feature isn't implemented. | |
eb05f173 | 13 | |
f2b9c257 RS |
14 | The best way to submit a patch is to make a pull request on GitHub. |
15 | (It is not necessary to send mail to rt@openssl.org to open a ticket!) | |
16 | If you think the patch could use feedback from the community, please | |
17 | start a thread on openssl-dev. | |
c5eed277 | 18 | |
f2b9c257 RS |
19 | You can also submit patches by sending it as mail to rt@opensslorg. |
20 | Please include the word "PATCH" and an explanation of what the patch | |
21 | does in the subject line. If you do this, our preferred format is "git | |
22 | format-patch" output. For example to provide a patch file containing the | |
23 | last commit in your local git repository use the following command: | |
f89ee71b | 24 | |
f2b9c257 | 25 | % git format-patch --stdout HEAD^ >mydiffs.patch |
f89ee71b MC |
26 | |
27 | Another method of creating an acceptable patch file without using git is as | |
28 | follows: | |
eb05f173 | 29 | |
f2b9c257 RS |
30 | % cd openssl-work |
31 | ...make your changes... | |
32 | % ./Configure dist; make clean | |
33 | % cd .. | |
34 | % diff -ur openssl-orig openssl-work >mydiffs.patch | |
35 | ||
36 | Note that pull requests are generally easier for the team, and community, to | |
37 | work with. Pull requests benefit from all of the standard GitHub features, | |
38 | including code review tools, simpler integration, and CI build support. | |
39 | ||
40 | No matter how a patch is submitted, the following items will help make | |
41 | the acceptance and review process faster: | |
42 | ||
43 | 1. Anything other than trivial contributions will require a contributor | |
44 | licensing agreement, giving us permission to use your code. See | |
45 | https://openssl.org/policies/cla.html for details. | |
46 | ||
47 | 2. All source files should start with the following text (with | |
48 | appropriate comment characters at the start of each line and the | |
49 | year(s) updated): | |
50 | ||
51 | Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved. | |
52 | ||
53 | Licensed under the OpenSSL license (the "License"). You may not use | |
54 | this file except in compliance with the License. You can obtain a copy | |
55 | in the file LICENSE in the source distribution or at | |
56 | https://www.openssl.org/source/license.html | |
57 | ||
58 | 3. Patches should be as current as possible. When using GitHub, please | |
59 | expect to have to rebase and update often. | |
60 | ||
61 | 3. Patches should follow our coding style (see | |
62 | https://www.openssl.org/policies/codingstyle.html) and compile without | |
63 | warnings using the --strict-warnings flag. OpenSSL compiles on many | |
64 | varied platforms: try to ensure you only use portable features. | |
65 | ||
66 | 4. When at all possible, patches should include tests. These can either be | |
67 | added to an existing test, or completely new. Please see test/README | |
68 | for information on the test framework. |