| 1 | HOW TO CONTRIBUTE TO OpenSSL
|
|---|
| 2 | ============================
|
|---|
| 3 |
|
|---|
| 4 | Please visit our [Getting Started] page for other ideas about how to contribute.
|
|---|
| 5 |
|
|---|
| 6 | [Getting Started]: <https://www.openssl.org/community/getting-started.html>
|
|---|
| 7 |
|
|---|
| 8 | Development is done on GitHub in the [openssl/openssl] repository.
|
|---|
| 9 |
|
|---|
| 10 | [openssl/openssl]: <https://github.com/openssl/openssl>
|
|---|
| 11 |
|
|---|
| 12 | To request new features or report bugs, please open an issue on GitHub
|
|---|
| 13 |
|
|---|
| 14 | To submit a patch, please open a pull request on GitHub. If you are thinking
|
|---|
| 15 | of making a large contribution, open an issue for it before starting work,
|
|---|
| 16 | to get comments from the community. Someone may be already working on
|
|---|
| 17 | the same thing, or there may be reasons why that feature isn't implemented.
|
|---|
| 18 |
|
|---|
| 19 | To make it easier to review and accept your pull request, please follow these
|
|---|
| 20 | guidelines:
|
|---|
| 21 |
|
|---|
| 22 | 1. Anything other than a trivial contribution requires a [Contributor
|
|---|
| 23 | License Agreement] (CLA), giving us permission to use your code.
|
|---|
| 24 | If your contribution is too small to require a CLA (e.g. fixing a spelling
|
|---|
| 25 | mistake), place the text "`CLA: trivial`" on a line by itself separated by
|
|---|
| 26 | an empty line from the rest of the commit message. It is not sufficient to
|
|---|
| 27 | only place the text in the GitHub pull request description.
|
|---|
| 28 |
|
|---|
| 29 | [Contributor License Agreement]: <https://www.openssl.org/policies/cla.html>
|
|---|
| 30 |
|
|---|
| 31 | To amend a missing "`CLA: trivial`" line after submission, do the following:
|
|---|
| 32 |
|
|---|
| 33 | ```
|
|---|
| 34 | git commit --amend
|
|---|
| 35 | [add the line, save and quit the editor]
|
|---|
| 36 | git push -f
|
|---|
| 37 | ```
|
|---|
| 38 |
|
|---|
| 39 | 2. All source files should start with the following text (with
|
|---|
| 40 | appropriate comment characters at the start of each line and the
|
|---|
| 41 | year(s) updated):
|
|---|
| 42 |
|
|---|
| 43 | ```
|
|---|
| 44 | Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved.
|
|---|
| 45 |
|
|---|
| 46 | Licensed under the Apache License 2.0 (the "License"). You may not use
|
|---|
| 47 | this file except in compliance with the License. You can obtain a copy
|
|---|
| 48 | in the file LICENSE in the source distribution or at
|
|---|
| 49 | https://www.openssl.org/source/license.html
|
|---|
| 50 | ```
|
|---|
| 51 |
|
|---|
| 52 | 3. Patches should be as current as possible; expect to have to rebase
|
|---|
| 53 | often. We do not accept merge commits, you will have to remove them
|
|---|
| 54 | (usually by rebasing) before it will be acceptable.
|
|---|
| 55 |
|
|---|
| 56 | 4. Patches should follow our [coding style] and compile without warnings.
|
|---|
| 57 | Where `gcc` or `clang` is available, you should use the
|
|---|
| 58 | `--strict-warnings` `Configure` option. OpenSSL compiles on many varied
|
|---|
| 59 | platforms: try to ensure you only use portable features. Clean builds via
|
|---|
| 60 | GitHub Actions and AppVeyor are required, and they are started automatically
|
|---|
| 61 | whenever a PR is created or updated.
|
|---|
| 62 |
|
|---|
| 63 | [coding style]: https://www.openssl.org/policies/technical/coding-style.html
|
|---|
| 64 |
|
|---|
| 65 | 5. When at all possible, patches should include tests. These can
|
|---|
| 66 | either be added to an existing test, or completely new. Please see
|
|---|
| 67 | [test/README.md](test/README.md) for information on the test framework.
|
|---|
| 68 |
|
|---|
| 69 | 6. New features or changed functionality must include
|
|---|
| 70 | documentation. Please look at the "pod" files in doc/man[1357] for
|
|---|
| 71 | examples of our style. Run "make doc-nits" to make sure that your
|
|---|
| 72 | documentation changes are clean.
|
|---|
| 73 |
|
|---|
| 74 | 7. For user visible changes (API changes, behaviour changes, ...),
|
|---|
| 75 | consider adding a note in [CHANGES.md](CHANGES.md).
|
|---|
| 76 | This could be a summarising description of the change, and could
|
|---|
| 77 | explain the grander details.
|
|---|
| 78 | Have a look through existing entries for inspiration.
|
|---|
| 79 | Please note that this is NOT simply a copy of git-log one-liners.
|
|---|
| 80 | Also note that security fixes get an entry in [CHANGES.md](CHANGES.md).
|
|---|
| 81 | This file helps users get more in depth information of what comes
|
|---|
| 82 | with a specific release without having to sift through the higher
|
|---|
| 83 | noise ratio in git-log.
|
|---|
| 84 |
|
|---|
| 85 | 8. For larger or more important user visible changes, as well as
|
|---|
| 86 | security fixes, please add a line in [NEWS.md](NEWS.md).
|
|---|
| 87 | On exception, it might be worth adding a multi-line entry (such as
|
|---|
| 88 | the entry that announces all the types that became opaque with
|
|---|
| 89 | OpenSSL 1.1.0).
|
|---|
| 90 | This file helps users get a very quick summary of what comes with a
|
|---|
| 91 | specific release, to see if an upgrade is worth the effort.
|
|---|
| 92 |
|
|---|
| 93 | 9. Guidelines how to integrate error output of new crypto library modules
|
|---|
| 94 | can be found in [crypto/err/README.md](crypto/err/README.md).
|
|---|
