Annotation of embedaddon/curl/docs/CONTRIBUTE.md, revision 1.1
1.1 ! misho 1: # Contributing to the curl project
! 2:
! 3: This document is intended to offer guidelines on how to best contribute to the
! 4: curl project. This concerns new features as well as corrections to existing
! 5: flaws or bugs.
! 6:
! 7: ## Learning curl
! 8:
! 9: ### Join the Community
! 10:
! 11: Skip over to [https://curl.haxx.se/mail/](https://curl.haxx.se/mail/) and join
! 12: the appropriate mailing list(s). Read up on details before you post
! 13: questions. Read this file before you start sending patches! We prefer
! 14: questions sent to and discussions being held on the mailing list(s), not sent
! 15: to individuals.
! 16:
! 17: Before posting to one of the curl mailing lists, please read up on the
! 18: [mailing list etiquette](https://curl.haxx.se/mail/etiquette.html).
! 19:
! 20: We also hang out on IRC in #curl on irc.freenode.net
! 21:
! 22: If you're at all interested in the code side of things, consider clicking
! 23: 'watch' on the [curl repo on github](https://github.com/curl/curl) to be
! 24: notified of pull requests and new issues posted there.
! 25:
! 26: ### License and copyright
! 27:
! 28: When contributing with code, you agree to put your changes and new code under
! 29: the same license curl and libcurl is already using unless stated and agreed
! 30: otherwise.
! 31:
! 32: If you add a larger piece of code, you can opt to make that file or set of
! 33: files to use a different license as long as they don't enforce any changes to
! 34: the rest of the package and they make sense. Such "separate parts" can not be
! 35: GPL licensed (as we don't want copyleft to affect users of libcurl) but they
! 36: must use "GPL compatible" licenses (as we want to allow users to use libcurl
! 37: properly in GPL licensed environments).
! 38:
! 39: When changing existing source code, you do not alter the copyright of the
! 40: original file(s). The copyright will still be owned by the original creator(s)
! 41: or those who have been assigned copyright by the original author(s).
! 42:
! 43: By submitting a patch to the curl project, you are assumed to have the right
! 44: to the code and to be allowed by your employer or whatever to hand over that
! 45: patch/code to us. We will credit you for your changes as far as possible, to
! 46: give credit but also to keep a trace back to who made what changes. Please
! 47: always provide us with your full real name when contributing!
! 48:
! 49: ### What To Read
! 50:
! 51: Source code, the man pages, the [INTERNALS
! 52: document](https://curl.haxx.se/dev/internals.html),
! 53: [TODO](https://curl.haxx.se/docs/todo.html),
! 54: [KNOWN_BUGS](https://curl.haxx.se/docs/knownbugs.html) and the [most recent
! 55: changes](https://curl.haxx.se/dev/sourceactivity.html) in git. Just lurking on
! 56: the [curl-library mailing
! 57: list](https://curl.haxx.se/mail/list.cgi?list=curl-library) will give you a
! 58: lot of insights on what's going on right now. Asking there is a good idea too.
! 59:
! 60: ## Write a good patch
! 61:
! 62: ### Follow code style
! 63:
! 64: When writing C code, follow the
! 65: [CODE_STYLE](https://curl.haxx.se/dev/code-style.html) already established in
! 66: the project. Consistent style makes code easier to read and mistakes less
! 67: likely to happen. Run `make checksrc` before you submit anything, to make sure
! 68: you follow the basic style. That script doesn't verify everything, but if it
! 69: complains you know you have work to do.
! 70:
! 71: ### Non-clobbering All Over
! 72:
! 73: When you write new functionality or fix bugs, it is important that you don't
! 74: fiddle all over the source files and functions. Remember that it is likely
! 75: that other people have done changes in the same source files as you have and
! 76: possibly even in the same functions. If you bring completely new
! 77: functionality, try writing it in a new source file. If you fix bugs, try to
! 78: fix one bug at a time and send them as separate patches.
! 79:
! 80: ### Write Separate Changes
! 81:
! 82: It is annoying when you get a huge patch from someone that is said to fix 511
! 83: odd problems, but discussions and opinions don't agree with 510 of them - or
! 84: 509 of them were already fixed in a different way. Then the person merging
! 85: this change needs to extract the single interesting patch from somewhere
! 86: within the huge pile of source, and that creates a lot of extra work.
! 87:
! 88: Preferably, each fix that corrects a problem should be in its own patch/commit
! 89: with its own description/commit message stating exactly what they correct so
! 90: that all changes can be selectively applied by the maintainer or other
! 91: interested parties.
! 92:
! 93: Also, separate changes enable bisecting much better for tracking problems
! 94: and regression in the future.
! 95:
! 96: ### Patch Against Recent Sources
! 97:
! 98: Please try to get the latest available sources to make your patches against.
! 99: It makes the lives of the developers so much easier. The very best is if you
! 100: get the most up-to-date sources from the git repository, but the latest
! 101: release archive is quite OK as well!
! 102:
! 103: ### Documentation
! 104:
! 105: Writing docs is dead boring and one of the big problems with many open source
! 106: projects. But someone's gotta do it! It makes things a lot easier if you
! 107: submit a small description of your fix or your new features with every
! 108: contribution so that it can be swiftly added to the package documentation.
! 109:
! 110: The documentation is always made in man pages (nroff formatted) or plain
! 111: ASCII files. All HTML files on the web site and in the release archives are
! 112: generated from the nroff/ASCII versions.
! 113:
! 114: ### Test Cases
! 115:
! 116: Since the introduction of the test suite, we can quickly verify that the main
! 117: features are working as they're supposed to. To maintain this situation and
! 118: improve it, all new features and functions that are added need to be tested
! 119: in the test suite. Every feature that is added should get at least one valid
! 120: test case that verifies that it works as documented. If every submitter also
! 121: posts a few test cases, it won't end up as a heavy burden on a single person!
! 122:
! 123: If you don't have test cases or perhaps you have done something that is very
! 124: hard to write tests for, do explain exactly how you have otherwise tested and
! 125: verified your changes.
! 126:
! 127: ## Sharing Your Changes
! 128:
! 129: ### How to get your changes into the main sources
! 130:
! 131: Ideally you file a [pull request on
! 132: github](https://github.com/curl/curl/pulls), but you can also send your plain
! 133: patch to [the curl-library mailing
! 134: list](https://curl.haxx.se/mail/list.cgi?list=curl-library).
! 135:
! 136: Either way, your change will be reviewed and discussed there and you will be
! 137: expected to correct flaws pointed out and update accordingly, or the change
! 138: risks stalling and eventually just getting deleted without action. As a
! 139: submitter of a change, you are the owner of that change until it has been merged.
! 140:
! 141: Respond on the list or on github about the change and answer questions and/or
! 142: fix nits/flaws. This is very important. We will take lack of replies as a
! 143: sign that you're not very anxious to get your patch accepted and we tend to
! 144: simply drop such changes.
! 145:
! 146: ### About pull requests
! 147:
! 148: With github it is easy to send a [pull
! 149: request](https://github.com/curl/curl/pulls) to the curl project to have
! 150: changes merged.
! 151:
! 152: We strongly prefer pull requests to mailed patches, as it makes it a proper
! 153: git commit that is easy to merge and they are easy to track and not that easy
! 154: to loose in the flood of many emails, like they sometimes do on the mailing
! 155: lists.
! 156:
! 157: Every pull request submitted will automatically be tested in several different
! 158: ways. Every pull request is verified for each of the following:
! 159:
! 160: - ... it still builds, warning-free, on Linux and macOS, with both
! 161: clang and gcc
! 162: - ... it still builds fine on Windows with several MSVC versions
! 163: - ... it still builds with cmake on Linux, with gcc and clang
! 164: - ... it follows rudimentary code style rules
! 165: - ... the test suite still runs 100% fine
! 166: - ... the release tarball (the "dist") still works
! 167: - ... it builds fine in-tree as well as out-of-tree
! 168: - ... code coverage doesn't shrink drastically
! 169:
! 170: If the pull-request fails one of these tests, it will show up as a red X and
! 171: you are expected to fix the problem. If you don't understand when the issue is
! 172: or have other problems to fix the complaint, just ask and other project
! 173: members will likely be able to help out.
! 174:
! 175: When you adjust your pull requests after review, consider squashing the
! 176: commits so that we can review the full updated version more easily.
! 177:
! 178: ### Making quality patches
! 179:
! 180: Make the patch against as recent source versions as possible.
! 181:
! 182: If you've followed the tips in this document and your patch still hasn't been
! 183: incorporated or responded to after some weeks, consider resubmitting it to the
! 184: list or better yet: change it to a pull request.
! 185:
! 186: ### Write good commit messages
! 187:
! 188: A short guide to how to write commit messages in the curl project.
! 189:
! 190: ---- start ----
! 191: [area]: [short line describing the main effect]
! 192: -- empty line --
! 193: [full description, no wider than 72 columns that describe as much as
! 194: possible as to why this change is made, and possibly what things
! 195: it fixes and everything else that is related]
! 196: -- empty line --
! 197: [Closes/Fixes #1234 - if this closes or fixes a github issue]
! 198: [Bug: URL to source of the report or more related discussion]
! 199: [Reported-by: John Doe - credit the reporter]
! 200: [whatever-else-by: credit all helpers, finders, doers]
! 201: ---- stop ----
! 202:
! 203: Don't forget to use commit --author="" if you commit someone else's work, and
! 204: make sure that you have your own user and email setup correctly in git before
! 205: you commit
! 206:
! 207: ### Write Access to git Repository
! 208:
! 209: If you are a very frequent contributor, you may be given push access to the
! 210: git repository and then you'll be able to push your changes straight into the
! 211: git repo instead of sending changes as pull requests or by mail as patches.
! 212:
! 213: Just ask if this is what you'd want. You will be required to have posted
! 214: several high quality patches first, before you can be granted push access.
! 215:
! 216: ### How To Make a Patch with git
! 217:
! 218: You need to first checkout the repository:
! 219:
! 220: git clone https://github.com/curl/curl.git
! 221:
! 222: You then proceed and edit all the files you like and you commit them to your
! 223: local repository:
! 224:
! 225: git commit [file]
! 226:
! 227: As usual, group your commits so that you commit all changes at once that
! 228: constitute a logical change.
! 229:
! 230: Once you have done all your commits and you're happy with what you see, you
! 231: can make patches out of your changes that are suitable for mailing:
! 232:
! 233: git format-patch remotes/origin/master
! 234:
! 235: This creates files in your local directory named NNNN-[name].patch for each
! 236: commit.
! 237:
! 238: Now send those patches off to the curl-library list. You can of course opt to
! 239: do that with the 'git send-email' command.
! 240:
! 241: ### How To Make a Patch without git
! 242:
! 243: Keep a copy of the unmodified curl sources. Make your changes in a separate
! 244: source tree. When you think you have something that you want to offer the
! 245: curl community, use GNU diff to generate patches.
! 246:
! 247: If you have modified a single file, try something like:
! 248:
! 249: diff -u unmodified-file.c my-changed-one.c > my-fixes.diff
! 250:
! 251: If you have modified several files, possibly in different directories, you
! 252: can use diff recursively:
! 253:
! 254: diff -ur curl-original-dir curl-modified-sources-dir > my-fixes.diff
! 255:
! 256: The GNU diff and GNU patch tools exist for virtually all platforms, including
! 257: all kinds of Unixes and Windows:
! 258:
! 259: For unix-like operating systems:
! 260:
! 261: - [https://savannah.gnu.org/projects/patch/](https://savannah.gnu.org/projects/patch/)
! 262: - [https://www.gnu.org/software/diffutils/](https://www.gnu.org/software/diffutils/)
! 263:
! 264: For Windows:
! 265:
! 266: - [https://gnuwin32.sourceforge.io/packages/patch.htm](https://gnuwin32.sourceforge.io/packages/patch.htm)
! 267: - [https://gnuwin32.sourceforge.io/packages/diffutils.htm](https://gnuwin32.sourceforge.io/packages/diffutils.htm)
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to CONTRIBUTE.md CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / curl / docs