The branch OpenSSL_1_0_2-stable has been updated
via c393a5de99b5c565a124af8f69936dadde77184f (commit)
from 48bacd31e88421fa413f0a62ef8e0285e3dbd402 (commit)
- Log -----------------------------------------------------------------
commit c393a5de99b5c565a124af8f69936dadde77184f
Author: Rich Salz <rs...@openssl.org>
Date: Wed May 11 16:46:44 2016 -0400
Recommend GH over RT, per team vote.
Reviewed-by: Richard Levitte <levi...@openssl.org>
(Manual cherry-pick of f2b9c257216a27b568b3d5d703ca5bdd926c5c28)
-----------------------------------------------------------------------
Summary of changes:
CONTRIBUTING | 86 ++++++++++++++++++++++++++++++++++++++++--------------------
1 file changed, 58 insertions(+), 28 deletions(-)
diff --git a/CONTRIBUTING b/CONTRIBUTING
index 9d63d8a..1bfbc1b 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -1,38 +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 r...@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 r...@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.
+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.
-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.
+The best way to submit a patch is to make a pull request on GitHub.
+(It is not necessary to send mail to r...@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.
_____
openssl-commits mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits
