| HOW TO CONTRIBUTE TO PATCHES OpenSSL |
| ------------------------------------ |
| |
| (Please visit https://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 http://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. |
| |
| The best way to submit a patch is to make a pull request on GitHub. |
| (It is not necessary to send mail to rt@openssl.org to open a ticket!) |
| If you think the patch could use feedback from the community, please |
| start a thread on openssl-dev. |
| |
| You can also submit patches by sending it as mail to rt@opensslorg. |
| Please include the word "PATCH" and an explanation of what the patch |
| does in the subject line. If you do this, our preferred format is "git |
| format-patch" output. For example to provide a patch file containing the |
| last commit in your local git repository use the following command: |
| |
| % git format-patch --stdout HEAD^ >mydiffs.patch |
| |
| Another method of creating an acceptable patch file without using git is as |
| follows: |
| |
| % cd openssl-work |
| ...make your changes... |
| % ./Configure dist; make clean |
| % cd .. |
| % diff -ur openssl-orig openssl-work >mydiffs.patch |
| |
| Note that pull requests are generally easier for the team, and community, to |
| work with. Pull requests benefit from all of the standard GitHub features, |
| including code review tools, simpler integration, and CI build support. |
| |
| No matter how a patch is submitted, the following items 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://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. When using GitHub, please |
| expect to have to rebase and update often. |
| |
| 3. Patches should follow our coding style (see |
| https://www.openssl.org/policies/codingstyle.html) and compile without |
| warnings using the --strict-warnings flag. OpenSSL compiles on many |
| varied platforms: try to ensure you only use portable features. |
| |
| 4. 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. |