### 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.
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.
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:
+
+ - ... it still builds, warning-free, on Linux and macOS, with both
+ clang and gcc
+ - ... it still builds fine on Windows with several MSVC versions
+ - ... it still builds with cmake on Linux, with gcc and clang
+ - ... it follows rudimentary code style rules
+ - ... the test suite still runs 100% fine
+ - ... the release tarball (the "dist") still works
+ - ... it builds fine in-tree as well as out-of-tree
+ - ... 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.
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
possible as to why this change is made, and possibly what things
it fixes and everything else that is related]
-- empty line --
+ [Closes/Fixes #1234 - if this closes or fixes a github issue]
[Bug: URL to source of the report or more related discussion]
[Reported-by: John Doe - credit the reporter]
[whatever-else-by: credit all helpers, finders, doers]
---- stop ----
-Don't forget to use commit --author="" if you commit someone else's work,
-and make sure that you have your own user and email setup correctly in git
-before you commit
+Don't forget to use commit --author="" if you commit someone else's work, and
+make sure that you have your own user and email setup correctly in git before
+you commit
### Write Access to git Repository
projects / platform / upstream / curl.git / blobdiff