diff options
Diffstat (limited to 'docs/CONTRIBUTE.md')
| -rw-r--r-- | docs/CONTRIBUTE.md | 36 |
1 files changed, 18 insertions, 18 deletions
diff --git a/docs/CONTRIBUTE.md b/docs/CONTRIBUTE.md index 8469b6043..b8254088f 100644 --- a/docs/CONTRIBUTE.md +++ b/docs/CONTRIBUTE.md @@ -19,7 +19,7 @@ Before posting to one of the curl mailing lists, please read up on the We also hang out on IRC in #curl on libera.chat -If you're at all interested in the code side of things, consider clicking +If you are at all interested in the code side of things, consider clicking 'watch' on the [curl repo on GitHub](https://github.com/curl/curl) to be notified of pull requests and new issues posted there. @@ -30,9 +30,9 @@ the same license curl and libcurl is already using unless stated and agreed otherwise. If you add a larger piece of code, you can opt to make that file or set of -files to use a different license as long as they don't enforce any changes to +files to use a different license as long as they do not enforce any changes to the rest of the package and they make sense. Such "separate parts" can not be -GPL licensed (as we don't want copyleft to affect users of libcurl) but they +GPL licensed (as we do not want copyleft to affect users of libcurl) but they must use "GPL compatible" licenses (as we want to allow users to use libcurl properly in GPL licensed environments). @@ -65,12 +65,12 @@ When writing C code, follow the [CODE_STYLE](https://curl.se/dev/code-style.html) already established in the project. Consistent style makes code easier to read and mistakes less likely to happen. Run `make checksrc` before you submit anything, to make sure -you follow the basic style. That script doesn't verify everything, but if it +you follow the basic style. That script does not verify everything, but if it complains you know you have work to do. ### Non-clobbering All Over -When you write new functionality or fix bugs, it is important that you don't +When you write new functionality or fix bugs, it is important that you do not fiddle all over the source files and functions. Remember that it is likely that other people have done changes in the same source files as you have and possibly even in the same functions. If you bring completely new @@ -80,7 +80,7 @@ fix one bug at a time and send them as separate patches. ### Write Separate Changes It is annoying when you get a huge patch from someone that is said to fix 511 -odd problems, but discussions and opinions don't agree with 510 of them - or +odd problems, but discussions and opinions do not agree with 510 of them - or 509 of them were already fixed in a different way. Then the person merging this change needs to extract the single interesting patch from somewhere within the huge pile of source, and that creates a lot of extra work. @@ -114,13 +114,13 @@ generated from the nroff/ASCII versions. ### Test Cases Since the introduction of the test suite, we can quickly verify that the main -features are working as they're supposed to. To maintain this situation and +features are working as they are supposed to. To maintain this situation and improve it, all new features and functions that are added need to be tested in the test suite. Every feature that is added should get at least one valid test case that verifies that it works as documented. If every submitter also -posts a few test cases, it won't end up as a heavy burden on a single person! +posts a few test cases, it will not end up as a heavy burden on a single person! -If you don't have test cases or perhaps you have done something that is hard +If you do not have test cases or perhaps you have done something that is hard to write tests for, do explain exactly how you have otherwise tested and verified your changes. @@ -140,7 +140,7 @@ submitter of a change, you are the owner of that change until it has been merged Respond on the list or on github about the change and answer questions and/or fix nits/flaws. This is important. We will take lack of replies as a sign that -you're not anxious to get your patch accepted and we tend to simply drop such +you are not anxious to get your patch accepted and we tend to simply drop such changes. ### About pull requests @@ -165,10 +165,10 @@ ways. Every pull request is verified for each of the following: - ... 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 + - ... code coverage does not 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 when the issue is +you are expected to fix the problem. If you do not understand when the issue is or have other problems to fix the complaint, just ask and other project members will likely be able to help out. @@ -205,7 +205,7 @@ 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 +If you have followed the tips in this document and your patch still has not been incorporated or responded to after some weeks, consider resubmitting it to the list or better yet: change it to a pull request. @@ -229,24 +229,24 @@ A short guide to how to write commit messages in the curl project. The first line is a succinct description of the change: - use the imperative, present tense: "change" not "changed" nor "changes" - - don't capitalize first letter + - do not capitalize first letter - no dot (.) at the end The `[area]` in the first line can be `http2`, `cookies`, `openssl` or similar. There's no fixed list to select from but using the same "area" as other related changes could make sense. -Don't forget to use commit --author="" if you commit someone else's work, and +Do not 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 If you are a frequent contributor, you may be given push access to the git -repository and then you'll be able to push your changes straight into the git +repository and then you will be able to push your changes straight into the git repo instead of sending changes as pull requests or by mail as patches. -Just ask if this is what you'd want. You will be required to have posted +Just ask if this is what you would want. You will be required to have posted several high quality patches first, before you can be granted push access. ### How To Make a Patch with git @@ -263,7 +263,7 @@ local repository: As usual, group your commits so that you commit all changes at once that constitute a logical change. -Once you have done all your commits and you're happy with what you see, you +Once you have done all your commits and you are happy with what you see, you can make patches out of your changes that are suitable for mailing: git format-patch remotes/origin/master |