reformatted to be similar to the FAQ to make it look nicer on the site:
http://curl.haxx.se/docs/contribute.html
This commit is contained in:
Daniel Stenberg
Родитель
da62aff6bb
Коммит
785a4899f5
|
|
@ -10,16 +10,46 @@
|
|||
mind when you decide to contribute to the project. This concerns new features
|
||||
as well as corrections to existing flaws or bugs.
|
||||
|
||||
Join the Community
|
||||
1. Learning cURL
|
||||
1.1 Join the Community
|
||||
1.2 License
|
||||
1.3 What To Read
|
||||
|
||||
2. cURL Coding Standards
|
||||
2.1 Naming
|
||||
2.2 Indenting
|
||||
2.3 Commenting
|
||||
2.4 Line Lengths
|
||||
2.5 General Style
|
||||
2.6 Non-clobbering All Over
|
||||
2.7 Platform Dependent Code
|
||||
2.8 Write Separate Patches
|
||||
2.9 Patch Against Recent Sources
|
||||
2.10 Document
|
||||
2.11 Test Cases
|
||||
|
||||
3. Pushing Out Your Changes
|
||||
3.1 Write Access to CVS Repository
|
||||
3.2 How To Make a Patch
|
||||
3.3 How to get your changes into the main sources
|
||||
|
||||
==============================================================================
|
||||
|
||||
1. Learning cURL
|
||||
|
||||
1.1 Join the Community
|
||||
|
||||
Skip over to http://curl.haxx.se/mail/ and join the appropriate mailing
|
||||
list(s). Read up on details before you post questions. Read this file before
|
||||
you start sending patches! We prefer patches and discussions being held on
|
||||
the mailing list(s), not sent to individuals.
|
||||
|
||||
Before posting to one of the curl mailing lists, please read up on the mailing
|
||||
list etiquette: http://curl.haxx.se/mail/etiquette.html
|
||||
|
||||
We also hang out on IRC in #curl on irc.freenode.net
|
||||
|
||||
License
|
||||
1.2. License
|
||||
|
||||
When contributing with code, you agree to put your changes and new code under
|
||||
the same license curl and libcurl is already using unless stated and agreed
|
||||
|
|
@ -43,14 +73,16 @@ License
|
|||
give credit but also to keep a trace back to who made what changes. Please
|
||||
always provide us with your full real name when contributing!
|
||||
|
||||
What To Read
|
||||
1.3 What To Read
|
||||
|
||||
Source code, the man pages, the INTERNALS document, TODO, KNOWN_BUGS, the
|
||||
most recent CHANGES. Just lurking on the libcurl mailing list is gonna give
|
||||
you a lot of insights on what's going on right now. Asking there is a good
|
||||
idea too.
|
||||
|
||||
Naming
|
||||
2. cURL Coding Standards
|
||||
|
||||
2.1 Naming
|
||||
|
||||
Try using a non-confusing naming scheme for your new functions and variable
|
||||
names. It doesn't necessarily have to mean that you should use the same as in
|
||||
|
|
@ -61,7 +93,7 @@ Naming
|
|||
See the INTERNALS document on how we name non-exported library-global
|
||||
symbols.
|
||||
|
||||
Indenting
|
||||
2.2 Indenting
|
||||
|
||||
Please try using the same indenting levels and bracing method as all the
|
||||
other code already does. It makes the source code a lot easier to follow if
|
||||
|
|
@ -70,7 +102,7 @@ Indenting
|
|||
using spaces only (no tabs) and having the opening brace ({) on the same line
|
||||
as the if() or while().
|
||||
|
||||
Commenting
|
||||
2.3 Commenting
|
||||
|
||||
Comment your source code extensively using C comments (/* comment */), DO NOT
|
||||
use C++ comments (// this style). Commented code is quality code and enables
|
||||
|
|
@ -78,16 +110,16 @@ Commenting
|
|||
replaced when someone wants to extend things, since other persons' source
|
||||
code can get quite hard to read.
|
||||
|
||||
Line Lengths
|
||||
2.4 Line Lengths
|
||||
|
||||
We try to keep source lines shorter than 80 columns.
|
||||
|
||||
General Style
|
||||
2.5 General Style
|
||||
|
||||
Keep your functions small. If they're small you avoid a lot of mistakes and
|
||||
you don't accidentally mix up variables etc.
|
||||
|
||||
Non-clobbering All Over
|
||||
2.6 Non-clobbering All Over
|
||||
|
||||
When you write new functionality or fix bugs, it is important that you don't
|
||||
fiddle all over the source files and functions. Remember that it is likely
|
||||
|
|
@ -96,14 +128,14 @@ Non-clobbering All Over
|
|||
functionality, try writing it in a new source file. If you fix bugs, try to
|
||||
fix one bug at a time and send them as separate patches.
|
||||
|
||||
Platform Dependent Code
|
||||
2.7 Platform Dependent Code
|
||||
|
||||
Use #ifdef HAVE_FEATURE to do conditional code. We avoid checking for
|
||||
particular operating systems or hardware in the #ifdef lines. The
|
||||
HAVE_FEATURE shall be generated by the configure script for unix-like systems
|
||||
and they are hard-coded in the config-[system].h files for the others.
|
||||
|
||||
Separate Patches
|
||||
2.8 Write Separate Patches
|
||||
|
||||
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
|
||||
|
|
@ -114,14 +146,14 @@ Separate Patches
|
|||
description exactly what they correct so that all patches can be selectively
|
||||
applied by the maintainer or other interested parties.
|
||||
|
||||
Patch Against Recent Sources
|
||||
2.9 Patch Against Recent Sources
|
||||
|
||||
Please try to get the latest available sources to make your patches
|
||||
against. It makes the life of the developers so much easier. The very best is
|
||||
if you get the most up-to-date sources from the CVS repository, but the
|
||||
latest release archive is quite OK as well!
|
||||
|
||||
Document
|
||||
2.10 Document
|
||||
|
||||
Writing docs is dead boring and one of the big problems with many open source
|
||||
projects. Someone's gotta do it. It makes it a lot easier if you submit a
|
||||
|
|
@ -132,16 +164,7 @@ Document
|
|||
ASCII files. All HTML files on the web site and in the release archives are
|
||||
generated from the nroff/ASCII versions.
|
||||
|
||||
Write Access to CVS Repository
|
||||
|
||||
If you are a frequent contributor, or have another good reason, you can of
|
||||
course get write access to the CVS repository and then you'll be able to
|
||||
check-in all your changes straight into the CVS tree instead of sending all
|
||||
changes by mail as patches. Just ask if this is what you'd want. You will be
|
||||
required to have posted a few quality patches first, before you can be
|
||||
granted write access.
|
||||
|
||||
Test Cases
|
||||
2.11 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
|
||||
|
|
@ -150,7 +173,18 @@ Test Cases
|
|||
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!
|
||||
|
||||
How To Make a Patch
|
||||
3. Pushing Out Your Changes
|
||||
|
||||
3.1 Write Access to CVS Repository
|
||||
|
||||
If you are a frequent contributor, or have another good reason, you can of
|
||||
course get write access to the CVS repository and then you'll be able to
|
||||
check-in all your changes straight into the CVS tree instead of sending all
|
||||
changes by mail as patches. Just ask if this is what you'd want. You will be
|
||||
required to have posted a few quality patches first, before you can be
|
||||
granted write access.
|
||||
|
||||
3.2 How To Make a Patch
|
||||
|
||||
Keep a copy of the unmodified curl sources. Make your changes in a separate
|
||||
source tree. When you think you have something that you want to offer the
|
||||
|
|
@ -170,15 +204,15 @@ How To Make a Patch
|
|||
|
||||
For unix-like operating systems:
|
||||
|
||||
http://www.gnu.org/software/patch/patch.html
|
||||
http://www.gnu.org/directory/diffutils.html
|
||||
http://www.gnu.org/software/patch/patch.html
|
||||
http://www.gnu.org/directory/diffutils.html
|
||||
|
||||
For Windows:
|
||||
|
||||
http://gnuwin32.sourceforge.net/packages/patch.htm
|
||||
http://gnuwin32.sourceforge.net/packages/diffutils.htm
|
||||
http://gnuwin32.sourceforge.net/packages/patch.htm
|
||||
http://gnuwin32.sourceforge.net/packages/diffutils.htm
|
||||
|
||||
How to get your patches into the libcurl sources
|
||||
3.3 How to get your changes into the main sources
|
||||
|
||||
1. Submit your patch to the curl-library mailing list
|
||||
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче