From: Rich Salz Date: Tue, 26 Apr 2016 19:50:28 +0000 (-0400) Subject: Recommend GH over RT, per team vote. X-Git-Tag: OpenSSL_1_1_0-pre6~864 X-Git-Url: https://git.librecmc.org/?a=commitdiff_plain;h=f2b9c257216a27b568b3d5d703ca5bdd926c5c28;p=oweals%2Fopenssl.git Recommend GH over RT, per team vote. Reviewed-by: Richard Levitte --- diff --git a/CONTRIBUTING b/CONTRIBUTING index 3b84ce3141..1bfbc1b835 100644 --- a/CONTRIBUTING +++ b/CONTRIBUTING @@ -1,42 +1,68 @@ -HOW TO CONTRIBUTE TO OpenSSL ----------------------------- +HOW TO CONTRIBUTE TO PATCHES OpenSSL +------------------------------------ -Development is coordinated on the openssl-dev mailing list (see -http://www.openssl.org for information on subscribing). If you -would like to submit a patch, send it to rt@openssl.org with -the string "[PATCH]" in the subject. Please be sure to include a -textual explanation of what your patch does. - -You can also make GitHub pull requests. If you do this, please also send -mail to rt@openssl.org with a brief description and a link to the PR so -that we can more easily keep track of it. +(Please visit https://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). If you are unsure as to whether a feature will be useful for the general -OpenSSL community please 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. - -Patches should be as up to date as possible, preferably relative to the -current Git or the last snapshot. They 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. +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. -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. +The best way to submit a patch is to make a pull request on GitHub. +(It is not necessary to send mail to rt@openssl.org to open a ticket!) +If you think the patch could use feedback from the community, please +start a thread on openssl-dev. -Our preferred format for patch files is "git format-patch" output. For example -to provide a patch file containing the last commit in your local git repository -use the following command: +You can also submit patches by sending it as mail to rt@opensslorg. +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 +last commit in your local git repository use the following command: -# git format-patch --stdout HEAD^ >mydiffs.patch + % git format-patch --stdout HEAD^ >mydiffs.patch Another method of creating an acceptable patch file without using git is as follows: -# cd openssl-work -# [your changes] -# ./Configure dist; make clean -# cd .. -# diff -ur openssl-orig openssl-work > mydiffs.patch + % cd openssl-work + ...make your changes... + % ./Configure dist; make clean + % cd .. + % diff -ur openssl-orig openssl-work >mydiffs.patch + +Note that pull requests are generally easier for the team, and community, to +work with. Pull requests benefit from all of the standard GitHub features, +including code review tools, simpler integration, and CI build support. + +No matter how a patch is submitted, the following items will help make +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. + + 2. All source files should start with the following text (with + appropriate comment characters at the start of each line and the + year(s) updated): + + Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved. + + Licensed under the OpenSSL license (the "License"). You may not use + this file except in compliance with the License. You can obtain a copy + in the file LICENSE in the source distribution or at + 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. + + 3. 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. + + 4. 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.