Lucas Eckels | 9bd90e6 | 2012-08-06 15:07:02 -0700 | [diff] [blame^] | 1 | _ _ ____ _ |
| 2 | ___| | | | _ \| | |
| 3 | / __| | | | |_) | | |
| 4 | | (__| |_| | _ <| |___ |
| 5 | \___|\___/|_| \_\_____| |
| 6 | |
| 7 | When Contributing Source Code |
| 8 | |
| 9 | This document is intended to offer guidelines that can be useful to keep in |
| 10 | mind when you decide to contribute to the project. This concerns new features |
| 11 | as well as corrections to existing flaws or bugs. |
| 12 | |
| 13 | 1. Learning cURL |
| 14 | 1.1 Join the Community |
| 15 | 1.2 License |
| 16 | 1.3 What To Read |
| 17 | |
| 18 | 2. cURL Coding Standards |
| 19 | 2.1 Naming |
| 20 | 2.2 Indenting |
| 21 | 2.3 Commenting |
| 22 | 2.4 Line Lengths |
| 23 | 2.5 General Style |
| 24 | 2.6 Non-clobbering All Over |
| 25 | 2.7 Platform Dependent Code |
| 26 | 2.8 Write Separate Patches |
| 27 | 2.9 Patch Against Recent Sources |
| 28 | 2.10 Document |
| 29 | 2.11 Test Cases |
| 30 | |
| 31 | 3. Pushing Out Your Changes |
| 32 | 3.1 Write Access to git Repository |
| 33 | 3.2 How To Make a Patch with git |
| 34 | 3.3 How To Make a Patch without git |
| 35 | 3.4 How to get your changes into the main sources |
| 36 | 3.5 Write good commit messages |
| 37 | |
| 38 | ============================================================================== |
| 39 | |
| 40 | 1. Learning cURL |
| 41 | |
| 42 | 1.1 Join the Community |
| 43 | |
| 44 | Skip over to http://curl.haxx.se/mail/ and join the appropriate mailing |
| 45 | list(s). Read up on details before you post questions. Read this file before |
| 46 | you start sending patches! We prefer patches and discussions being held on |
| 47 | the mailing list(s), not sent to individuals. |
| 48 | |
| 49 | Before posting to one of the curl mailing lists, please read up on the mailing |
| 50 | list etiquette: http://curl.haxx.se/mail/etiquette.html |
| 51 | |
| 52 | We also hang out on IRC in #curl on irc.freenode.net |
| 53 | |
| 54 | 1.2. License |
| 55 | |
| 56 | When contributing with code, you agree to put your changes and new code under |
| 57 | the same license curl and libcurl is already using unless stated and agreed |
| 58 | otherwise. |
| 59 | |
| 60 | If you add a larger piece of code, you can opt to make that file or set of |
| 61 | files to use a different license as long as they don't enforce any changes to |
| 62 | the rest of the package and they make sense. Such "separate parts" can not be |
| 63 | GPL licensed (as we don't want copyleft to affect users of libcurl) but they |
| 64 | must use "GPL compatible" licenses (as we want to allow users to use libcurl |
| 65 | properly in GPL licensed environments). |
| 66 | |
| 67 | When changing existing source code, you do not alter the copyright of the |
| 68 | original file(s). The copyright will still be owned by the original |
| 69 | creator(s) or those who have been assigned copyright by the original |
| 70 | author(s). |
| 71 | |
| 72 | By submitting a patch to the curl project, you are assumed to have the right |
| 73 | to the code and to be allowed by your employer or whatever to hand over that |
| 74 | patch/code to us. We will credit you for your changes as far as possible, to |
| 75 | give credit but also to keep a trace back to who made what changes. Please |
| 76 | always provide us with your full real name when contributing! |
| 77 | |
| 78 | 1.3 What To Read |
| 79 | |
| 80 | Source code, the man pages, the INTERNALS document, TODO, KNOWN_BUGS, the |
| 81 | most recent CHANGES. Just lurking on the libcurl mailing list is gonna give |
| 82 | you a lot of insights on what's going on right now. Asking there is a good |
| 83 | idea too. |
| 84 | |
| 85 | 2. cURL Coding Standards |
| 86 | |
| 87 | 2.1 Naming |
| 88 | |
| 89 | Try using a non-confusing naming scheme for your new functions and variable |
| 90 | names. It doesn't necessarily have to mean that you should use the same as in |
| 91 | other places of the code, just that the names should be logical, |
| 92 | understandable and be named according to what they're used for. File-local |
| 93 | functions should be made static. We like lower case names. |
| 94 | |
| 95 | See the INTERNALS document on how we name non-exported library-global |
| 96 | symbols. |
| 97 | |
| 98 | 2.2 Indenting |
| 99 | |
| 100 | Please try using the same indenting levels and bracing method as all the |
| 101 | other code already does. It makes the source code a lot easier to follow if |
| 102 | all of it is written using the same style. We don't ask you to like it, we |
| 103 | just ask you to follow the tradition! ;-) This mainly means: 2-level indents, |
| 104 | using spaces only (no tabs) and having the opening brace ({) on the same line |
| 105 | as the if() or while(). |
| 106 | |
| 107 | Also note that we use if() and while() with no space before the parenthesis. |
| 108 | |
| 109 | 2.3 Commenting |
| 110 | |
| 111 | Comment your source code extensively using C comments (/* comment */), DO NOT |
| 112 | use C++ comments (// this style). Commented code is quality code and enables |
| 113 | future modifications much more. Uncommented code risk having to be completely |
| 114 | replaced when someone wants to extend things, since other persons' source |
| 115 | code can get quite hard to read. |
| 116 | |
| 117 | 2.4 Line Lengths |
| 118 | |
| 119 | We write source lines shorter than 80 columns. |
| 120 | |
| 121 | 2.5 General Style |
| 122 | |
| 123 | Keep your functions small. If they're small you avoid a lot of mistakes and |
| 124 | you don't accidentally mix up variables etc. |
| 125 | |
| 126 | 2.6 Non-clobbering All Over |
| 127 | |
| 128 | When you write new functionality or fix bugs, it is important that you don't |
| 129 | fiddle all over the source files and functions. Remember that it is likely |
| 130 | that other people have done changes in the same source files as you have and |
| 131 | possibly even in the same functions. If you bring completely new |
| 132 | functionality, try writing it in a new source file. If you fix bugs, try to |
| 133 | fix one bug at a time and send them as separate patches. |
| 134 | |
| 135 | 2.7 Platform Dependent Code |
| 136 | |
| 137 | Use #ifdef HAVE_FEATURE to do conditional code. We avoid checking for |
| 138 | particular operating systems or hardware in the #ifdef lines. The |
| 139 | HAVE_FEATURE shall be generated by the configure script for unix-like systems |
| 140 | and they are hard-coded in the config-[system].h files for the others. |
| 141 | |
| 142 | 2.8 Write Separate Patches |
| 143 | |
| 144 | It is annoying when you get a huge patch from someone that is said to fix 511 |
| 145 | odd problems, but discussions and opinions don't agree with 510 of them - or |
| 146 | 509 of them were already fixed in a different way. Then the patcher needs to |
| 147 | extract the single interesting patch from somewhere within the huge pile of |
| 148 | source, and that gives a lot of extra work. Preferably, all fixes that |
| 149 | correct different problems should be in their own patch with an attached |
| 150 | description exactly what they correct so that all patches can be selectively |
| 151 | applied by the maintainer or other interested parties. |
| 152 | |
| 153 | 2.9 Patch Against Recent Sources |
| 154 | |
| 155 | Please try to get the latest available sources to make your patches |
| 156 | against. It makes the life of the developers so much easier. The very best is |
| 157 | if you get the most up-to-date sources from the git repository, but the |
| 158 | latest release archive is quite OK as well! |
| 159 | |
| 160 | 2.10 Document |
| 161 | |
| 162 | Writing docs is dead boring and one of the big problems with many open source |
| 163 | projects. Someone's gotta do it. It makes it a lot easier if you submit a |
| 164 | small description of your fix or your new features with every contribution so |
| 165 | that it can be swiftly added to the package documentation. |
| 166 | |
| 167 | The documentation is always made in man pages (nroff formatted) or plain |
| 168 | ASCII files. All HTML files on the web site and in the release archives are |
| 169 | generated from the nroff/ASCII versions. |
| 170 | |
| 171 | 2.11 Test Cases |
| 172 | |
| 173 | Since the introduction of the test suite, we can quickly verify that the main |
| 174 | features are working as they're supposed to. To maintain this situation and |
| 175 | improve it, all new features and functions that are added need to be tested |
| 176 | in the test suite. Every feature that is added should get at least one valid |
| 177 | test case that verifies that it works as documented. If every submitter also |
| 178 | posts a few test cases, it won't end up as a heavy burden on a single person! |
| 179 | |
| 180 | 3. Pushing Out Your Changes |
| 181 | |
| 182 | 3.1 Write Access to git Repository |
| 183 | |
| 184 | If you are a frequent contributor, or have another good reason, you can of |
| 185 | course get write access to the git repository and then you'll be able to push |
| 186 | your changes straight into the git repo instead of sending changes by mail as |
| 187 | patches. Just ask if this is what you'd want. You will be required to have |
| 188 | posted a few quality patches first, before you can be granted push access. |
| 189 | |
| 190 | 3.2 How To Make a Patch with git |
| 191 | |
| 192 | You need to first checkout the respository: |
| 193 | |
| 194 | git clone git://github.com/bagder/curl.git |
| 195 | |
| 196 | You then proceed and edit all the files you like and you commit them to your |
| 197 | local repository: |
| 198 | |
| 199 | git commit [file] |
| 200 | |
| 201 | As usual, group your commits so that you commit all changes that at once that |
| 202 | constitutes a logical change. See also section "3.5 Write good commit |
| 203 | messages". |
| 204 | |
| 205 | Once you have done all your commits and you're happy with what you see, you |
| 206 | can make patches out of your changes that are suitable for mailing: |
| 207 | |
| 208 | git format-patch remotes/origin/master |
| 209 | |
| 210 | This creates files in your local directory named NNNN-[name].patch for each |
| 211 | commit. |
| 212 | |
| 213 | Now send those patches off to the curl-library list. You can of course opt to |
| 214 | do that with the 'get send-email' command. |
| 215 | |
| 216 | 3.3 How To Make a Patch without git |
| 217 | |
| 218 | Keep a copy of the unmodified curl sources. Make your changes in a separate |
| 219 | source tree. When you think you have something that you want to offer the |
| 220 | curl community, use GNU diff to generate patches. |
| 221 | |
| 222 | If you have modified a single file, try something like: |
| 223 | |
| 224 | diff -u unmodified-file.c my-changed-one.c > my-fixes.diff |
| 225 | |
| 226 | If you have modified several files, possibly in different directories, you |
| 227 | can use diff recursively: |
| 228 | |
| 229 | diff -ur curl-original-dir curl-modified-sources-dir > my-fixes.diff |
| 230 | |
| 231 | The GNU diff and GNU patch tools exist for virtually all platforms, including |
| 232 | all kinds of Unixes and Windows: |
| 233 | |
| 234 | For unix-like operating systems: |
| 235 | |
| 236 | http://www.gnu.org/software/patch/patch.html |
| 237 | http://www.gnu.org/directory/diffutils.html |
| 238 | |
| 239 | For Windows: |
| 240 | |
| 241 | http://gnuwin32.sourceforge.net/packages/patch.htm |
| 242 | http://gnuwin32.sourceforge.net/packages/diffutils.htm |
| 243 | |
| 244 | 3.4 How to get your changes into the main sources |
| 245 | |
| 246 | 1. Submit your patch to the curl-library mailing list |
| 247 | |
| 248 | 2. Make the patch against as recent sources as possible. |
| 249 | |
| 250 | 3. Make sure your patch adheres to the source indent and coding style of |
| 251 | already existing source code. Failing to do so just adds more work for me. |
| 252 | |
| 253 | 4. Respond to replies on the list about the patch and answer questions and/or |
| 254 | fix nits/flaws. This is very important. I will take lack of replies as a |
| 255 | sign that you're not very anxious to get your patch accepted and I tend to |
| 256 | simply drop such patches from my TODO list. |
| 257 | |
| 258 | 5. If you've followed the above mentioned paragraphs and your patch still |
| 259 | hasn't been incorporated after some weeks, consider resubmitting it to the |
| 260 | list. |
| 261 | |
| 262 | 3.5 Write good commit messages |
| 263 | |
| 264 | A short guide to how to do fine commit messages in the curl project. |
| 265 | |
| 266 | ---- start ---- |
| 267 | [area]: [short line describing the main effect] |
| 268 | |
| 269 | [separate the above single line from the rest with an empty line] |
| 270 | |
| 271 | [full description, no wider than 72 columns that describe as much as |
| 272 | possible as to why this change is made, and possibly what things |
| 273 | it fixes and everything else that is related] |
| 274 | ---- stop ---- |
| 275 | |
| 276 | Don't forget to use commit --author="" if you commit someone else's work, |
| 277 | and make sure that you have your own user and email setup correctly in git |
| 278 | before you commit |
| 279 | |