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)
This commit is contained in:
Rich Salz 2016-10-12 15:49:06 -04:00
parent 16b42d4d35
commit 7954dced19
2 changed files with 24 additions and 62 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
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.
(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.
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.
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
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:
Having addressed the following items before the PR 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
@ -55,21 +33,22 @@ the acceptance and review process faster:
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. Note that we do not accept merge
commits. You will be asked to remove them before a patch is considered
acceptable.
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.
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
--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.
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.
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.
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.

33
README
View file

@ -59,13 +59,13 @@
If you have any problems with OpenSSL then please take the following steps
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
- Remove ASM versions of libraries
- Configure with no-asm
- Remove compiler optimisation flags
If you wish to report a bug then please include the following information in
any bug report:
If you wish to report a bug then please include the following information
and create an issue on GitHub:
- OpenSSL version: output of 'openssl version -a'
- Any "Configure" options that you selected during compilation of the
@ -76,27 +76,10 @@
- Problem Description (steps that will reproduce the problem, if known)
- 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 couple of days for the ticket to show up. (We also scan posts to make
sure that security disclosures aren't publicly 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
is necessarily a bug in OpenSSL. Use the openssl-users email list for this type
of query.
You can also make GitHub pull requests. See the CONTRIBUTING file for more
details.
HOW TO CONTRIBUTE TO OpenSSL
----------------------------
@ -105,7 +88,7 @@
LEGALITIES
----------
A number of nations, in particular the U.S., restrict the use or export
of cryptography. If you are potentially subject to such restrictions
you should seek competent professional legal advice before attempting to
develop or distribute cryptographic code.
A number of nations, restrict the use or export of cryptography. If you
are potentially subject to such restrictions you should seek competent
professional legal advice before attempting to develop or distribute
cryptographic code.