Commit e8e380ce authored by Rich Salz's avatar Rich Salz
Browse files

RT is put out to pasture 



Reviewed-by: default avatarTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1702)
(cherry picked from commit 7954dced)
parent f1f97699

CONTRIBUTING

+16 −37
Original line number Original line Diff line number Diff line
@@ -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.

README

+8 −26
Original line number Original line Diff line number Diff line
@@ -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.