diff options
author | Matt Caswell <matt@openssl.org> | 2016-06-03 17:12:08 +0100 |
---|---|---|
committer | Matt Caswell <matt@openssl.org> | 2016-06-03 17:12:08 +0100 |
commit | 733f72f182f420282bc248441cbf34a0f3721e7f (patch) | |
tree | dc894c05416a53998ac4db61425133c3083062b5 | |
parent | a004e72b95835136d3f1ea90517f706c24c03da7 (diff) |
Update CONTRIBUTING
Fix typos and clarify a few things in the CONTRIBUTING file.
Reviewed-by: Rich Salz <rsalz@openssl.org>
-rw-r--r-- | CONTRIBUTING | 25 |
1 files changed, 16 insertions, 9 deletions
diff --git a/CONTRIBUTING b/CONTRIBUTING index 1bfbc1b835..07115e5a75 100644 --- a/CONTRIBUTING +++ b/CONTRIBUTING @@ -1,11 +1,11 @@ HOW TO CONTRIBUTE TO PATCHES OpenSSL ------------------------------------ -(Please visit https://openssl.org/community/getting-started.html for +(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 http://mta.openssl.org for information on subscribing). +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 @@ -16,7 +16,7 @@ The best way to submit a patch is to make a pull request on GitHub. 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. +You can also submit patches by sending it as mail to rt@openssl.org. 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 @@ -42,7 +42,7 @@ 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. + https://www.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 @@ -56,13 +56,20 @@ the acceptance and review process faster: 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. + expect to have to rebase and update often. Note that we do not accept merge + commits. You will be asked to remove them before a patch is considered + acceptable. - 3. Patches should follow our coding style (see + 4. 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. + warnings. Where gcc or clang is availble you should use the + --strict-warnings Configure option. 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 + 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/apps, doc/crypto and doc/ssl for examples of + our style. |