mirror of
https://github.com/openssl/openssl.git
synced 2024-11-23 18:13:39 +08:00
Updated to CONTRIBUTING to reflect GitHub, etc.
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5889)
This commit is contained in:
parent
69b1500291
commit
2876872ffe
51
CONTRIBUTING
51
CONTRIBUTING
@ -1,26 +1,26 @@
|
||||
HOW TO CONTRIBUTE PATCHES TO OpenSSL
|
||||
------------------------------------
|
||||
HOW TO CONTRIBUTE TO OpenSSL
|
||||
----------------------------
|
||||
|
||||
(Please visit https://www.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 https://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.
|
||||
Development is done on GitHub, https://github.com/openssl/openssl.
|
||||
|
||||
To submit a patch, make a pull request on GitHub. If you think the patch
|
||||
could use feedback from the community, please start a thread on openssl-dev
|
||||
to discuss it.
|
||||
To request new features or report bugs, please open an issue on GitHub
|
||||
|
||||
Having addressed the following items before the PR will help make the
|
||||
acceptance and review process faster:
|
||||
To submit a patch, please open a pull request on GitHub. If you are thinking
|
||||
of making a large contribution, open an issue for it before starting work,
|
||||
to get comments from the community. Someone may be already working on
|
||||
the same thing or there may be reasons why that feature isn't implemented.
|
||||
|
||||
1. Anything other than trivial contributions will require a contributor
|
||||
licensing agreement, giving us permission to use your code. See
|
||||
https://www.openssl.org/policies/cla.html for details.
|
||||
To make it easier to review and accept your pull request, please follow these
|
||||
guidelines:
|
||||
|
||||
1. Anything other than a trivial contribution requires a Contributor
|
||||
License Agreement (CLA), giving us permission to use your code. See
|
||||
https://www.openssl.org/policies/cla.html for details. If your
|
||||
contribution is too small to require a CLA, put "CLA: trivial" on a
|
||||
line by itself in your commit message body.
|
||||
|
||||
2. All source files should start with the following text (with
|
||||
appropriate comment characters at the start of each line and the
|
||||
@ -34,21 +34,22 @@ acceptance and review process faster:
|
||||
https://www.openssl.org/source/license.html
|
||||
|
||||
3. Patches should be as current as possible; expect to have to rebase
|
||||
often. We do not accept merge commits; You will be asked to remove
|
||||
them before a patch is considered acceptable.
|
||||
often. We do not accept merge commits, you will have to remove them
|
||||
(usually by rebasing) before it will be acceptable.
|
||||
|
||||
4. Patches should follow our coding style (see
|
||||
https://www.openssl.org/policies/codingstyle.html) and compile without
|
||||
warnings. Where gcc or clang is available you should use the
|
||||
https://www.openssl.org/policies/codingstyle.html) and compile
|
||||
without warnings. Where gcc or clang is available you should use the
|
||||
--strict-warnings Configure option. OpenSSL compiles on many varied
|
||||
platforms: try to ensure you only use portable features.
|
||||
Clean builds via Travis and AppVeyor are expected, and done whenever
|
||||
a PR is created or updated.
|
||||
platforms: try to ensure you only use portable features. Clean builds
|
||||
via Travis and AppVeyor are required, and they are started automatically
|
||||
whenever a PR is created or updated.
|
||||
|
||||
5. 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.
|
||||
|
||||
6. New features or changed functionality must include
|
||||
documentation. Please look at the "pod" files in doc/man[1357]
|
||||
for examples of our style.
|
||||
documentation. Please look at the "pod" files in doc/man[1357] for
|
||||
examples of our style. Run "make doc-nits" to make sure that your
|
||||
documentation changes are clean.
|
||||
|
Loading…
Reference in New Issue
Block a user