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