CONTRIBUTING revision 1.1
1 HOW TO CONTRIBUTE PATCHES TO OpenSSL 2 ------------------------------------ 3 4 (Please visit https://www.openssl.org/community/getting-started.html for 5 other ideas about how to contribute.) 6 7 Development is coordinated on the openssl-dev mailing list (see the 8 above link or https://mta.openssl.org for information on subscribing). 9 If you are unsure as to whether a feature will be useful for the general 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. 13 14 To submit a patch, make a pull request on GitHub. If you think the patch 15 could use feedback from the community, please start a thread on openssl-dev 16 to discuss it. 17 18 Having addressed the following items before the PR will help make the 19 acceptance and review process faster: 20 21 1. Anything other than trivial contributions will require a contributor 22 licensing agreement, giving us permission to use your code. See 23 https://www.openssl.org/policies/cla.html for details. 24 25 2. All source files should start with the following text (with 26 appropriate comment characters at the start of each line and the 27 year(s) updated): 28 29 Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved. 30 31 Licensed under the OpenSSL license (the "License"). You may not use 32 this file except in compliance with the License. You can obtain a copy 33 in the file LICENSE in the source distribution or at 34 https://www.openssl.org/source/license.html 35 36 3. Patches should be as current as possible; expect to have to rebase 37 often. We do not accept merge commits; You will be asked to remove 38 them before a patch is considered acceptable. 39 40 4. Patches should follow our coding style (see 41 https://www.openssl.org/policies/codingstyle.html) and compile without 42 warnings. Where gcc or clang is availble you should use the 43 --strict-warnings Configure option. OpenSSL compiles on many varied 44 platforms: try to ensure you only use portable features. 45 Clean builds via Travis and AppVeyor are expected, and done whenever 46 a PR is created or updated. 47 48 5. When at all possible, patches should include tests. These can 49 either be added to an existing test, or completely new. Please see 50 test/README for information on the test framework. 51 52 6. New features or changed functionality must include 53 documentation. Please look at the "pod" files in doc/apps, doc/crypto 54 and doc/ssl for examples of our style. 55
Indexes created Tue Oct 27 00:25:24 UTC 2026