| 1 | HOW TO CONTRIBUTE 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 done on GitHub, https://github.com/openssl/openssl.
|
|---|
| 8 |
|
|---|
| 9 | To request new features or report bugs, please open an issue on GitHub
|
|---|
| 10 |
|
|---|
| 11 | To submit a patch, please open a pull request on GitHub. If you are thinking
|
|---|
| 12 | of making a large contribution, open an issue for it before starting work,
|
|---|
| 13 | to get comments from the community. Someone may be already working on
|
|---|
| 14 | the same thing or there may be reasons why that feature isn't implemented.
|
|---|
| 15 |
|
|---|
| 16 | To make it easier to review and accept your pull request, please follow these
|
|---|
| 17 | guidelines:
|
|---|
| 18 |
|
|---|
| 19 | 1. Anything other than a trivial contribution requires a Contributor
|
|---|
| 20 | License Agreement (CLA), giving us permission to use your code. See
|
|---|
| 21 | https://www.openssl.org/policies/cla.html for details. If your
|
|---|
| 22 | contribution is too small to require a CLA, put "CLA: trivial" on a
|
|---|
| 23 | line by itself in your commit message body.
|
|---|
| 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 have to remove them
|
|---|
| 38 | (usually by rebasing) before it will be acceptable.
|
|---|
| 39 |
|
|---|
| 40 | 4. Patches should follow our coding style (see
|
|---|
| 41 | https://www.openssl.org/policies/codingstyle.html) and compile
|
|---|
| 42 | without warnings. Where gcc or clang is available you should use the
|
|---|
| 43 | --strict-warnings Configure option. OpenSSL compiles on many varied
|
|---|
| 44 | platforms: try to ensure you only use portable features. Clean builds
|
|---|
| 45 | via Travis and AppVeyor are required, and they are started automatically
|
|---|
| 46 | whenever 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/man[1357] for
|
|---|
| 54 | examples of our style. Run "make doc-nits" to make sure that your
|
|---|
| 55 | documentation changes are clean.
|
|---|
| 56 |
|
|---|
| 57 | 7. For user visible changes (API changes, behaviour changes, ...),
|
|---|
| 58 | consider adding a note in CHANGES. This could be a summarising
|
|---|
| 59 | description of the change, and could explain the grander details.
|
|---|
| 60 | Have a look through existing entries for inspiration.
|
|---|
| 61 | Please note that this is NOT simply a copy of git-log one-liners.
|
|---|
| 62 | Also note that security fixes get an entry in CHANGES.
|
|---|
| 63 | This file helps users get more in depth information of what comes
|
|---|
| 64 | with a specific release without having to sift through the higher
|
|---|
| 65 | noise ratio in git-log.
|
|---|
| 66 |
|
|---|
| 67 | 8. For larger or more important user visible changes, as well as
|
|---|
| 68 | security fixes, please add a line in NEWS. On exception, it might be
|
|---|
| 69 | worth adding a multi-line entry (such as the entry that announces all
|
|---|
| 70 | the types that became opaque with OpenSSL 1.1.0).
|
|---|
| 71 | This file helps users get a very quick summary of what comes with a
|
|---|
| 72 | specific release, to see if an upgrade is worth the effort.
|
|---|
