mirror of https://github.com/moparisthebest/curl
CONTRIBUTE: refreshed
This commit is contained in:
parent
296c180bb7
commit
1af5958978
146
docs/CONTRIBUTE
146
docs/CONTRIBUTE
|
@ -23,13 +23,14 @@
|
||||||
2.5 Document
|
2.5 Document
|
||||||
2.6 Test Cases
|
2.6 Test Cases
|
||||||
|
|
||||||
3. Pushing Out Your Changes
|
3. Sharing Your Changes
|
||||||
3.1 Write Access to git Repository
|
3.1 How to get your changes into the main sources
|
||||||
3.2 How To Make a Patch with git
|
3.2 About pull requests
|
||||||
3.3 How To Make a Patch without git
|
3.3 Making quality patches
|
||||||
3.4 How to get your changes into the main sources
|
|
||||||
3.5 Write good commit messages
|
3.5 Write good commit messages
|
||||||
3.6 About pull requests
|
3.6 Write Access to git Repository
|
||||||
|
3.7 How To Make a Patch with git
|
||||||
|
3.8 How To Make a Patch without git
|
||||||
|
|
||||||
==============================================================================
|
==============================================================================
|
||||||
|
|
||||||
|
@ -88,7 +89,9 @@
|
||||||
|
|
||||||
When writing C code, follow the CODE_STYLE already established in the
|
When writing C code, follow the CODE_STYLE already established in the
|
||||||
project. Consistent style makes code easier to read and mistakes less likely
|
project. Consistent style makes code easier to read and mistakes less likely
|
||||||
to happen.
|
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
|
||||||
|
complains you know you have work to do.
|
||||||
|
|
||||||
2.2 Non-clobbering All Over
|
2.2 Non-clobbering All Over
|
||||||
|
|
||||||
|
@ -144,17 +147,76 @@
|
||||||
hard to write tests for, do explain exactly how you have otherwise tested and
|
hard to write tests for, do explain exactly how you have otherwise tested and
|
||||||
verified your changes.
|
verified your changes.
|
||||||
|
|
||||||
3. Pushing Out Your Changes
|
3. Sharing Your Changes
|
||||||
|
|
||||||
3.1 Write Access to git Repository
|
3.1 How to get your changes into the main sources
|
||||||
|
|
||||||
If you are a frequent contributor, or have another good reason, you can of
|
Ideally you file a pull request on github, but you can also send your plain
|
||||||
course get write access to the git repository and then you'll be able to push
|
patch to the curl-library mailing list.
|
||||||
your changes straight into the git repo instead of sending 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 push access.
|
|
||||||
|
|
||||||
3.2 How To Make a Patch with git
|
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
|
||||||
|
risk stalling and eventually just get deleted without action. As a 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 very important. We will take lack of replies as a
|
||||||
|
sign that you're not very anxious to get your patch accepted and we tend to
|
||||||
|
simply drop such changes.
|
||||||
|
|
||||||
|
3.2 About pull requests
|
||||||
|
|
||||||
|
With github it is easy to send a pull request to the curl project to have
|
||||||
|
changes merged this way instead of mailing patches to the curl-library
|
||||||
|
mailing list. See https://github.com/curl/curl/pulls
|
||||||
|
|
||||||
|
We prefer pull requests 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 a flood of
|
||||||
|
many emails, like they sometimes do on the mailing lists.
|
||||||
|
|
||||||
|
When you ajust your pull requests after review, consider squashing the
|
||||||
|
commits so that we can review the full updated version more easily.
|
||||||
|
|
||||||
|
3.3 Making quality patches
|
||||||
|
|
||||||
|
Make the patch against as recent sources 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.
|
||||||
|
|
||||||
|
3.5 Write good commit messages
|
||||||
|
|
||||||
|
A short guide to how to do fine commit messages in the curl project.
|
||||||
|
|
||||||
|
---- start ----
|
||||||
|
[area]: [short line describing the main effect]
|
||||||
|
|
||||||
|
[separate the above single line from the rest with an empty line]
|
||||||
|
|
||||||
|
[full description, no wider than 72 columns that describe as much as
|
||||||
|
possible as to why this change is made, and possibly what things
|
||||||
|
it fixes and everything else that is related]
|
||||||
|
|
||||||
|
[Bug: link 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
|
||||||
|
|
||||||
|
3.6 Write Access to git Repository
|
||||||
|
|
||||||
|
If you are a very 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 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
|
||||||
|
several high quality patches first, before you can be granted push access.
|
||||||
|
|
||||||
|
3.7 How To Make a Patch with git
|
||||||
|
|
||||||
You need to first checkout the repository:
|
You need to first checkout the repository:
|
||||||
|
|
||||||
|
@ -180,7 +242,7 @@
|
||||||
Now send those patches off to the curl-library list. You can of course opt to
|
Now send those patches off to the curl-library list. You can of course opt to
|
||||||
do that with the 'git send-email' command.
|
do that with the 'git send-email' command.
|
||||||
|
|
||||||
3.3 How To Make a Patch without git
|
3.8 How To Make a Patch without git
|
||||||
|
|
||||||
Keep a copy of the unmodified curl sources. Make your changes in a separate
|
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
|
source tree. When you think you have something that you want to offer the
|
||||||
|
@ -207,55 +269,3 @@
|
||||||
|
|
||||||
http://gnuwin32.sourceforge.net/packages/patch.htm
|
http://gnuwin32.sourceforge.net/packages/patch.htm
|
||||||
http://gnuwin32.sourceforge.net/packages/diffutils.htm
|
http://gnuwin32.sourceforge.net/packages/diffutils.htm
|
||||||
|
|
||||||
3.4 How to get your changes into the main sources
|
|
||||||
|
|
||||||
Submit your patch to the curl-library mailing list.
|
|
||||||
|
|
||||||
Make the patch against as recent sources as possible.
|
|
||||||
|
|
||||||
Make sure your patch adheres to the source indent and coding style of already
|
|
||||||
existing source code. Failing to do so just adds more work for me.
|
|
||||||
|
|
||||||
Respond to replies on the list about the patch and answer questions and/or
|
|
||||||
fix nits/flaws. This is very important. I will take lack of replies as a sign
|
|
||||||
that you're not very anxious to get your patch accepted and I tend to simply
|
|
||||||
drop such patches from my TODO list.
|
|
||||||
|
|
||||||
If you've followed the above paragraphs and your patch still hasn't been
|
|
||||||
incorporated after some weeks, consider resubmitting it to the list.
|
|
||||||
|
|
||||||
3.5 Write good commit messages
|
|
||||||
|
|
||||||
A short guide to how to do fine commit messages in the curl project.
|
|
||||||
|
|
||||||
---- start ----
|
|
||||||
[area]: [short line describing the main effect]
|
|
||||||
|
|
||||||
[separate the above single line from the rest with an empty line]
|
|
||||||
|
|
||||||
[full description, no wider than 72 columns that describe as much as
|
|
||||||
possible as to why this change is made, and possibly what things
|
|
||||||
it fixes and everything else that is related]
|
|
||||||
|
|
||||||
[Bug: link 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
|
|
||||||
|
|
||||||
3.6 About pull requests
|
|
||||||
|
|
||||||
With git (and especially github) it is easy and tempting to send a pull
|
|
||||||
request to the curl project to have changes merged this way instead of
|
|
||||||
mailing patches to the curl-library mailing list.
|
|
||||||
|
|
||||||
We used to dislike this but we're trying to change that and accept that this
|
|
||||||
is a frictionless way for people to contribute to the project. We now welcome
|
|
||||||
pull requests!
|
|
||||||
|
|
||||||
We will continue to avoid using github's merge tools to make the history
|
|
||||||
linear and to make sure commits follow our style guidelines.
|
|
||||||
|
|
Loading…
Reference in New Issue