You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
54 lines
2.5 KiB
54 lines
2.5 KiB
HOW TO CONTRIBUTE PATCHES TO OpenSSL |
|
------------------------------------ |
|
|
|
(Please visit https://www.openssl.org/community/getting-started.html for |
|
other ideas about how to contribute.) |
|
|
|
Development is coordinated on the openssl-dev mailing list (see the |
|
above link or https://mta.openssl.org for information on subscribing). |
|
If you are unsure as to whether a feature will be useful for the general |
|
OpenSSL community you might want to discuss it on the openssl-dev mailing |
|
list first. Someone may be already working on the same thing or there |
|
may be a good reason as to why that feature isn't implemented. |
|
|
|
To submit a patch, make a pull request on GitHub. If you think the patch |
|
could use feedback from the community, please start a thread on openssl-dev |
|
to discuss it. |
|
|
|
Having addressed the following items before the PR will help make the |
|
acceptance and review process faster: |
|
|
|
1. Anything other than trivial contributions will require a contributor |
|
licensing agreement, giving us permission to use your code. See |
|
https://www.openssl.org/policies/cla.html for details. |
|
|
|
2. All source files should start with the following text (with |
|
appropriate comment characters at the start of each line and the |
|
year(s) updated): |
|
|
|
Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved. |
|
|
|
Licensed under the OpenSSL license (the "License"). You may not use |
|
this file except in compliance with the License. You can obtain a copy |
|
in the file LICENSE in the source distribution or at |
|
https://www.openssl.org/source/license.html |
|
|
|
3. Patches should be as current as possible; expect to have to rebase |
|
often. We do not accept merge commits; You will be asked to remove |
|
them before a patch is considered acceptable. |
|
|
|
4. Patches should follow our coding style (see |
|
https://www.openssl.org/policies/codingstyle.html) and compile without |
|
warnings. Where gcc or clang is availble you should use the |
|
--strict-warnings Configure option. OpenSSL compiles on many varied |
|
platforms: try to ensure you only use portable features. |
|
Clean builds via Travis and AppVeyor are expected, and done whenever |
|
a PR is created or updated. |
|
|
|
5. When at all possible, patches should include tests. These can |
|
either be added to an existing test, or completely new. Please see |
|
test/README for information on the test framework. |
|
|
|
6. New features or changed functionality must include |
|
documentation. Please look at the "pod" files in doc/apps, doc/crypto |
|
and doc/ssl for examples of our style.
|
|
|