Fix no-posix-io compile failure

[openssl.git] / CONTRIBUTING

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 1bfbc1b8350c8a5a223979cd74bc29ac0dfbd429..08c607aad2a4e0a29b8dfab8fe5989d0be8aafdc 100644 (file)
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -1,48 +1,26 @@
-HOW TO CONTRIBUTE TO PATCHES OpenSSL
+HOW TO CONTRIBUTE PATCHES TO OpenSSL

 ------------------------------------
 
 ------------------------------------
 

-(Please visit https://openssl.org/community/getting-started.html for
+(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
 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).
+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.
 
 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.
 

-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@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
-
-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
 
     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.
+    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
 
     2.  All source files should start with the following text (with
     appropriate comment characters at the start of each line and the


@@ -55,14 +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
 
         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 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.

 
 

-    3.  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 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.
+    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.
+
+    6.  New features or changed functionality must include
+    documentation. Please look at the "pod" files in doc/man[1357]
+    for examples of our style.