| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455 |
- 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 available 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.
|
