From c3ad22697c261d266db8620c3594b669e34881d9 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Sun, 4 Jun 2017 00:19:57 +0200 Subject: 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 -- cgit v1.2.1