reinstall

1 files changed, 0 insertions, 54 deletions

diff --git a/openssl/CONTRIBUTING b/openssl/CONTRIBUTING
deleted file mode 100644
index f734d77..0000000
--- a/openssl/CONTRIBUTING
+++ /dev/null
@@ -1,54 +0,0 @@
-HOW TO CONTRIBUTE PATCHES TO OpenSSL
-------------------------------------
-
-(Please visit https://www.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 https://mta.openssl.org for information on subscribing).
-If you are unsure as to whether a feature will be useful for the general
-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.
-
-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.
-
-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
-    https://www.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; 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 availble 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.
-
-    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.