moparisthebest/curl
1
0
Fork 0
mirror of https://github.com/moparisthebest/curl synced 2025-03-11 07:39:50 -04:00
Code Issues Releases Wiki Activity

CONTRIBUTE.md: mention tests done on pull requests

Browse Source
This commit is contained in:
Daniel Stenberg 2017-06-04 00:19:57 +02:00
parent 7bbb78c741
commit c3ad22697c
1 changed files with 25 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
docs/CONTRIBUTE.md
View File

@ -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