wbrawner/openssl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

RT is put out to pasture

Browse source 
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1702)
(cherry picked from commit 7954dced19)
This commit is contained in:
Rich Salz 2016-10-12 15:49:06 -04:00
parent 52a69c480d
commit 329a5f3615
2 changed files with 24 additions and 63 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

53
CONTRIBUTING
View file

@ -11,34 +11,12 @@ 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 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. may be a good reason as to why that feature isn't implemented.
The best way to submit a patch is to make a pull request on GitHub. To submit a patch, make a pull request on GitHub. If you think the patch
(It is not necessary to send mail to rt@openssl.org to open a ticket!) could use feedback from the community, please start a thread on openssl-dev
If you think the patch could use feedback from the community, please to discuss it.
start a thread on openssl-dev.
You can also submit patches by sending it as mail to rt@openssl.org. Having addressed the following items before the PR will help make the
Please include the word "PATCH" and an explanation of what the patch acceptance and review process faster:
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
Another method of creating an acceptable patch file without using git is as
follows:
% 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 1. Anything other than trivial contributions will require a contributor
licensing agreement, giving us permission to use your code. See licensing agreement, giving us permission to use your code. See
@ -55,21 +33,22 @@ the acceptance and review process faster:
in the file LICENSE in the source distribution or at in the file LICENSE in the source distribution or at
https://www.openssl.org/source/license.html https://www.openssl.org/source/license.html
3. Patches should be as current as possible. When using GitHub, please 3. Patches should be as current as possible; expect to have to rebase
expect to have to rebase and update often. Note that we do not accept merge often. We do not accept merge commits; You will be asked to remove
commits. You will be asked to remove them before a patch is considered them before a patch is considered acceptable.
acceptable.
4. 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 https://www.openssl.org/policies/codingstyle.html) and compile without
warnings. Where gcc or clang is availble you should use the warnings. Where gcc or clang is availble you should use the
--strict-warnings Configure option. OpenSSL compiles on many varied --strict-warnings Configure option. OpenSSL compiles on many varied
platforms: try to ensure you only use portable features. 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.
5. When at all possible, patches should include tests. These can either be 5. When at all possible, patches should include tests. These can
added to an existing test, or completely new. Please see test/README either be added to an existing test, or completely new. Please see
for information on the test framework. test/README for information on the test framework.
6. New features or changed functionality must include documentation. Please 6. New features or changed functionality must include
look at the "pod" files in doc/apps, doc/crypto and doc/ssl for examples of documentation. Please look at the "pod" files in doc/apps, doc/crypto
our style. and doc/ssl for examples of our style.

34
README
View file

@ -66,13 +66,13 @@
If you have any problems with OpenSSL then please take the following steps If you have any problems with OpenSSL then please take the following steps
first: first:
- Download the current snapshot from ftp://ftp.openssl.org/snapshot/ - Download the latest version from the repository
to see if the problem has already been addressed to see if the problem has already been addressed
- Remove ASM versions of libraries - Configure with no-asm
- Remove compiler optimisation flags - Remove compiler optimisation flags
If you wish to report a bug then please include the following information in If you wish to report a bug then please include the following information
any bug report: and create an issue on GitHub:
- On Unix systems: - On Unix systems:
Self-test report generated by 'make report' Self-test report generated by 'make report'
@ -84,27 +84,9 @@
- Problem Description (steps that will reproduce the problem, if known) - Problem Description (steps that will reproduce the problem, if known)
- Stack Traceback (if the application dumps core) - Stack Traceback (if the application dumps core)
Email the report to:
rt@openssl.org
In order to avoid spam, this is a moderated mailing list, and it might
take a day for the ticket to show up. (We also scan posts to make sure
that security disclosures aren't publically posted by mistake.) Mail
to this address is recorded in the public RT (request tracker) database
(see https://www.openssl.org/community/index.html#bugs for details) and
also forwarded the public openssl-dev mailing list. Confidential mail
may be sent to openssl-security@openssl.org (PGP key available from the
key servers).
Please do NOT use this for general assistance or support queries.
Just because something doesn't work the way you expect does not mean it Just because something doesn't work the way you expect does not mean it
is necessarily a bug in OpenSSL. is necessarily a bug in OpenSSL.
You can also make GitHub pull requests. If you do this, please also send
mail to rt@openssl.org with a link to the PR so that we can more easily
keep track of it.
HOW TO CONTRIBUTE TO OpenSSL HOW TO CONTRIBUTE TO OpenSSL
---------------------------- ----------------------------
@ -113,7 +95,7 @@
LEGALITIES LEGALITIES
---------- ----------
A number of nations, in particular the U.S., restrict the use or export A number of nations, restrict the use or export of cryptography. If you
of cryptography. If you are potentially subject to such restrictions are potentially subject to such restrictions you should seek competent
you should seek competent professional legal advice before attempting to professional legal advice before attempting to develop or distribute
develop or distribute cryptographic code. cryptographic code.