[GNUnet-SVN] [gnurl] 220/254: CONTRIBUTE.md: mention tests done on pull requests

[gnunet]

This is an automated email from the git hooks/post-receive script.

ng0 pushed a commit to annotated tag gnurl-7.54.1
in repository gnurl.

commit c3ad22697c261d266db8620c3594b669e34881d9
Author: Daniel Stenberg <address@hidden>
AuthorDate: Sun Jun 4 00:19:57 2017 +0200

    CONTRIBUTE.md: mention tests done on pull requests
---
 docs/CONTRIBUTE.md | 32 +++++++++++++++++++++++++-------
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/docs/CONTRIBUTE.md b/docs/CONTRIBUTE.md
index ba803c34f..7d3c2e073 100644
--- a/docs/CONTRIBUTE.md
+++ b/docs/CONTRIBUTE.md
@@ -103,7 +103,7 @@ release archive is quite OK as well!
 ### Documentation
 
 Writing docs is dead boring and one of the big problems with many open source
-projects. But someone's gotta do it! It makes things a lot easier if you 
+projects. But someone's gotta do it! It makes things a lot easier if you
 submit a small description of your fix or your new features with every
 contribution so that it can be swiftly added to the package documentation.
 
@@ -134,7 +134,7 @@ patch to [the curl-library mailing
 list](https://curl.haxx.se/mail/list.cgi?list=curl-library).
 
 Either way, your change will be reviewed and discussed there and you will be
-expected to correct flaws pointed out and update accordingly, or the change 
+expected to correct flaws pointed out and update accordingly, or the change
 risks stalling and eventually just getting deleted without action. As a
 submitter of a change, you are the owner of that change until it has been 
merged.
 
@@ -149,9 +149,27 @@ With github it is easy to send a [pull
 request](https://github.com/curl/curl/pulls) to the curl project to have
 changes merged.
 
-We prefer pull requests to mailed patches, as it makes it a proper git commit
-that is easy to merge and they are easy to track and not that easy to loose
-in the flood of many emails, like they sometimes do on the mailing lists.
+We strongly prefer pull requests to mailed patches, as it makes it a proper
+git commit that is easy to merge and they are easy to track and not that easy
+to loose in the flood of many emails, like they sometimes do on the mailing
+lists.
+
+Every pull request submitted will automatically be tested in several different
+ways. Every pull request is verfied that:
+
+ - ... the code still builds, warning-free, on Linux and macOS, with both
+   clang and gcc
+ - ... the code still builds fine on Windows with several MSVC versions
+ - ... the code still builds with cmake on Linux, with gcc and clang
+ - ... the code follows rudimentary code style rules
+ - ... the test suite still runs 100% fine
+ - ... the release tarball (the "dist") still works
+ - ... the code coverage doesn't shrink drastically
+
+If the pull-request fails one of these tests, it will show up as a red X and
+you are expected to fix the problem. If you don't understand whan the issue is
+or have other problems to fix the complaint, just ask and other project
+members will likely be able to help out.
 
 When you adjust your pull requests after review, consider squashing the
 commits so that we can review the full updated version more easily.
@@ -161,8 +179,8 @@ commits so that we can review the full updated version more 
easily.
 Make the patch against as recent source versions as possible.
 
 If you've followed the tips in this document and your patch still hasn't been
-incorporated or responded to after some weeks, consider resubmitting it to
-the list or better yet: change it to a pull request.
+incorporated or responded to after some weeks, consider resubmitting it to the
+list or better yet: change it to a pull request.
 
 ### Write good commit messages
 

-- 
To stop receiving notification emails like this one, please contact
address@hidden