2016-08-09 17:39:58 +08:00
|
|
|
# Contributing to the curl project
|
2000-05-23 01:35:35 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
This document is intended to offer guidelines on how to best contribute to the
|
|
|
|
curl project. This concerns new features as well as corrections to existing
|
|
|
|
flaws or bugs.
|
2007-09-20 22:43:31 +08:00
|
|
|
|
2022-06-21 22:56:19 +08:00
|
|
|
## Join the Community
|
2000-08-01 06:42:34 +08:00
|
|
|
|
2020-11-04 21:02:01 +08:00
|
|
|
Skip over to [https://curl.se/mail/](https://curl.se/mail/) and join
|
2021-11-26 15:46:59 +08:00
|
|
|
the appropriate mailing list(s). Read up on details before you post
|
|
|
|
questions. Read this file before you start sending patches. We prefer
|
2016-08-09 17:39:58 +08:00
|
|
|
questions sent to and discussions being held on the mailing list(s), not sent
|
|
|
|
to individuals.
|
2005-10-28 15:22:45 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
Before posting to one of the curl mailing lists, please read up on the
|
2020-11-04 21:02:01 +08:00
|
|
|
[mailing list etiquette](https://curl.se/mail/etiquette.html).
|
2005-10-28 15:22:45 +08:00
|
|
|
|
2021-05-24 06:21:00 +08:00
|
|
|
We also hang out on IRC in #curl on libera.chat
|
2000-05-23 01:35:35 +08:00
|
|
|
|
2021-10-31 23:34:44 +08:00
|
|
|
If you are at all interested in the code side of things, consider clicking
|
2021-04-28 01:53:43 +08:00
|
|
|
'watch' on the [curl repo on GitHub](https://github.com/curl/curl) to be
|
2019-02-05 11:42:10 +08:00
|
|
|
notified of pull requests and new issues posted there.
|
2001-08-29 23:02:46 +08:00
|
|
|
|
2022-06-21 22:56:19 +08:00
|
|
|
## License and copyright
|
2001-08-29 23:02:46 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
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
|
|
|
|
otherwise.
|
2007-09-20 22:43:31 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
If you add a larger piece of code, you can opt to make that file or set of
|
2021-10-31 23:34:44 +08:00
|
|
|
files to use a different license as long as they do not enforce any changes to
|
2016-08-09 17:39:58 +08:00
|
|
|
the rest of the package and they make sense. Such "separate parts" can not be
|
2021-10-31 23:34:44 +08:00
|
|
|
GPL licensed (as we do not want copyleft to affect users of libcurl) but they
|
2016-08-09 17:39:58 +08:00
|
|
|
must use "GPL compatible" licenses (as we want to allow users to use libcurl
|
|
|
|
properly in GPL licensed environments).
|
2000-05-23 01:35:35 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
When changing existing source code, you do not alter the copyright of the
|
|
|
|
original file(s). The copyright will still be owned by the original creator(s)
|
|
|
|
or those who have been assigned copyright by the original author(s).
|
2002-10-08 15:11:34 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
By submitting a patch to the curl project, you are assumed to have the right
|
|
|
|
to the code and to be allowed by your employer or whatever to hand over that
|
|
|
|
patch/code to us. We will credit you for your changes as far as possible, to
|
|
|
|
give credit but also to keep a trace back to who made what changes. Please
|
2021-11-26 15:46:59 +08:00
|
|
|
always provide us with your full real name when contributing,
|
2000-05-23 01:35:35 +08:00
|
|
|
|
2022-06-21 22:56:19 +08:00
|
|
|
## What To Read
|
2000-05-23 01:35:35 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
Source code, the man pages, the [INTERNALS
|
2020-11-04 21:02:01 +08:00
|
|
|
document](https://curl.se/dev/internals.html),
|
|
|
|
[TODO](https://curl.se/docs/todo.html),
|
|
|
|
[KNOWN_BUGS](https://curl.se/docs/knownbugs.html) and the [most recent
|
|
|
|
changes](https://curl.se/dev/sourceactivity.html) in git. Just lurking on
|
2016-08-09 17:39:58 +08:00
|
|
|
the [curl-library mailing
|
2020-11-04 21:02:01 +08:00
|
|
|
list](https://curl.se/mail/list.cgi?list=curl-library) will give you a
|
2016-08-09 17:39:58 +08:00
|
|
|
lot of insights on what's going on right now. Asking there is a good idea too.
|
2000-05-23 01:35:35 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
## Write a good patch
|
2000-05-23 01:35:35 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
### Follow code style
|
2013-08-06 20:12:45 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
When writing C code, follow the
|
2020-11-04 21:02:01 +08:00
|
|
|
[CODE_STYLE](https://curl.se/dev/code-style.html) already established in
|
2016-08-09 17:39:58 +08:00
|
|
|
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
|
2021-10-31 23:34:44 +08:00
|
|
|
you follow the basic style. That script does not verify everything, but if it
|
2016-08-09 17:39:58 +08:00
|
|
|
complains you know you have work to do.
|
2001-01-04 20:43:35 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
### Non-clobbering All Over
|
2001-01-04 20:43:35 +08:00
|
|
|
|
2021-10-31 23:34:44 +08:00
|
|
|
When you write new functionality or fix bugs, it is important that you do not
|
2016-08-09 17:39:58 +08:00
|
|
|
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
|
|
|
|
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.
|
2000-05-23 01:35:35 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
### Write Separate Changes
|
2000-05-23 01:35:35 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
It is annoying when you get a huge patch from someone that is said to fix 511
|
2021-10-31 23:34:44 +08:00
|
|
|
odd problems, but discussions and opinions do not agree with 510 of them - or
|
2016-08-09 17:39:58 +08:00
|
|
|
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
|
2017-01-14 20:01:06 +08:00
|
|
|
within the huge pile of source, and that creates a lot of extra work.
|
2002-10-08 15:11:34 +08:00
|
|
|
|
2017-01-14 20:01:06 +08:00
|
|
|
Preferably, each fix that corrects a problem should be in its own patch/commit
|
2016-08-09 17:39:58 +08:00
|
|
|
with its own description/commit message stating exactly what they correct so
|
|
|
|
that all changes can be selectively applied by the maintainer or other
|
|
|
|
interested parties.
|
2000-11-29 15:48:14 +08:00
|
|
|
|
2017-01-14 20:01:06 +08:00
|
|
|
Also, separate changes enable bisecting much better for tracking problems
|
2016-08-09 17:39:58 +08:00
|
|
|
and regression in the future.
|
2002-11-28 22:07:14 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
### Patch Against Recent Sources
|
2013-08-06 20:12:45 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
Please try to get the latest available sources to make your patches against.
|
2021-11-01 20:43:11 +08:00
|
|
|
It makes the lives of the developers so much easier. The best is if you get
|
|
|
|
the most up-to-date sources from the git repository, but the latest release
|
2021-11-26 15:46:59 +08:00
|
|
|
archive is quite OK as well.
|
2007-09-20 22:43:31 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
### Documentation
|
2007-09-20 22:43:31 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
Writing docs is dead boring and one of the big problems with many open source
|
2021-12-09 19:03:35 +08:00
|
|
|
projects. But someone's gotta do it. It makes things a lot easier if you
|
2017-01-14 20:01:06 +08:00
|
|
|
submit a small description of your fix or your new features with every
|
|
|
|
contribution so that it can be swiftly added to the package documentation.
|
2007-09-20 22:43:31 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
The documentation is always made in man pages (nroff formatted) or plain
|
2020-08-17 04:36:10 +08:00
|
|
|
ASCII files. All HTML files on the website and in the release archives are
|
2016-08-09 17:39:58 +08:00
|
|
|
generated from the nroff/ASCII versions.
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
### Test Cases
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
Since the introduction of the test suite, we can quickly verify that the main
|
2021-10-31 23:34:44 +08:00
|
|
|
features are working as they are supposed to. To maintain this situation and
|
2016-08-09 17:39:58 +08:00
|
|
|
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
|
2021-10-31 23:34:44 +08:00
|
|
|
posts a few test cases, it will not end up as a heavy burden on a single person!
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2021-10-31 23:34:44 +08:00
|
|
|
If you do not have test cases or perhaps you have done something that is hard
|
2021-11-01 20:43:11 +08:00
|
|
|
to write tests for, do explain exactly how you have otherwise tested and
|
2016-08-09 17:39:58 +08:00
|
|
|
verified your changes.
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2022-06-21 22:56:19 +08:00
|
|
|
## Submit Your Changes
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
### How to get your changes into the main sources
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
Ideally you file a [pull request on
|
2021-04-28 01:53:43 +08:00
|
|
|
GitHub](https://github.com/curl/curl/pulls), but you can also send your plain
|
2016-08-09 17:39:58 +08:00
|
|
|
patch to [the curl-library mailing
|
2020-11-04 21:02:01 +08:00
|
|
|
list](https://curl.se/mail/list.cgi?list=curl-library).
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2022-06-21 22:56:19 +08:00
|
|
|
If you opt to post a patch on the mailing list, chances are someone will
|
|
|
|
convert it into a pull request for you, to have the CI jobs verify it proper
|
|
|
|
before it can be merged. Be prepared that some feedback on the proposed change
|
|
|
|
might then come on GitHub.
|
|
|
|
|
|
|
|
Your change will be reviewed and discussed and you will be expected to correct
|
|
|
|
flaws pointed out and update accordingly, or the change risks stalling and
|
|
|
|
eventually just getting deleted without action. As a submitter of a change,
|
|
|
|
you are the owner of that change until it has been merged.
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2022-06-21 22:56:19 +08:00
|
|
|
Respond on the list or on GitHub about the change and answer questions and/or
|
2021-11-01 20:43:11 +08:00
|
|
|
fix nits/flaws. This is important. We will take lack of replies as a sign that
|
2021-10-31 23:34:44 +08:00
|
|
|
you are not anxious to get your patch accepted and we tend to simply drop such
|
2021-11-01 20:43:11 +08:00
|
|
|
changes.
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
### About pull requests
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2022-10-26 14:59:35 +08:00
|
|
|
With GitHub it is easy to send a [pull
|
2016-08-09 17:39:58 +08:00
|
|
|
request](https://github.com/curl/curl/pulls) to the curl project to have
|
|
|
|
changes merged.
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2017-06-04 06:19:57 +08:00
|
|
|
We strongly prefer pull requests to mailed patches, as it makes it a proper
|
|
|
|
git commit that is easy to merge and they are easy to track and not that easy
|
2021-07-18 08:45:38 +08:00
|
|
|
to lose in the flood of many emails, like they sometimes do on the mailing
|
2017-06-04 06:19:57 +08:00
|
|
|
lists.
|
|
|
|
|
2022-09-21 05:30:19 +08:00
|
|
|
Every pull request submitted will automatically be tested in several different
|
|
|
|
ways. [See the CI document for more
|
2021-11-16 13:00:26 +08:00
|
|
|
information](https://github.com/curl/curl/blob/master/tests/CI.md).
|
2020-08-29 15:56:22 +08:00
|
|
|
|
|
|
|
Sometimes the tests fail due to a dependency service temporarily being offline
|
2022-09-21 05:30:19 +08:00
|
|
|
or otherwise unavailable, e.g. package downloads. In this case you can just
|
2020-08-29 15:56:22 +08:00
|
|
|
try to update your pull requests to rerun the tests later as described below.
|
|
|
|
|
|
|
|
You can update your pull requests by pushing new commits or force-pushing
|
|
|
|
changes to existing commits. Force-pushing an amended commit without any
|
|
|
|
actual content changed also allows you to retrigger the tests for that commit.
|
|
|
|
|
2016-10-01 02:49:48 +08:00
|
|
|
When you adjust your pull requests after review, consider squashing the
|
2016-08-09 17:39:58 +08:00
|
|
|
commits so that we can review the full updated version more easily.
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2022-05-25 05:40:50 +08:00
|
|
|
A pull request sent to the project might get labeled `needs-votes` by a
|
|
|
|
project maintainer. This label means that in addition to meeting all other
|
|
|
|
checks and qualifications this pull request must also receive more "votes" of
|
|
|
|
user support. More signs that people want this to happen. It could be in the
|
|
|
|
form of messages saying so, or thumbs-up reactions on GitHub.
|
|
|
|
|
2022-06-21 22:56:19 +08:00
|
|
|
### Making quality changes
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2017-01-14 20:01:06 +08:00
|
|
|
Make the patch against as recent source versions as possible.
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2022-06-21 22:56:19 +08:00
|
|
|
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.
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2022-06-21 22:56:19 +08:00
|
|
|
### Commit messages
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
A short guide to how to write commit messages in the curl project.
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
---- start ----
|
|
|
|
[area]: [short line describing the main effect]
|
|
|
|
-- 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]
|
|
|
|
-- empty line --
|
2017-03-21 07:41:56 +08:00
|
|
|
[Closes/Fixes #1234 - if this closes or fixes a github issue]
|
2016-08-09 17:39:58 +08:00
|
|
|
[Bug: URL 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 ----
|
2016-08-09 16:53:42 +08:00
|
|
|
|
2020-08-11 22:49:57 +08:00
|
|
|
The first line is a succinct description of the change:
|
|
|
|
|
|
|
|
- use the imperative, present tense: "change" not "changed" nor "changes"
|
2021-10-31 23:34:44 +08:00
|
|
|
- do not capitalize first letter
|
2020-08-11 22:49:57 +08:00
|
|
|
- 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.
|
|
|
|
|
2021-10-31 23:34:44 +08:00
|
|
|
Do not forget to use commit --author="" if you commit someone else's work, and
|
2017-03-21 07:41:56 +08:00
|
|
|
make sure that you have your own user and email setup correctly in git before
|
|
|
|
you commit
|
2010-03-22 07:34:09 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
### Write Access to git Repository
|
2010-04-12 17:20:00 +08:00
|
|
|
|
2021-11-01 20:43:11 +08:00
|
|
|
If you are a frequent contributor, you may be given push access to the git
|
2021-10-31 23:34:44 +08:00
|
|
|
repository and then you will be able to push your changes straight into the git
|
2021-11-01 20:43:11 +08:00
|
|
|
repo instead of sending changes as pull requests or by mail as patches.
|
2010-04-12 17:20:00 +08:00
|
|
|
|
2021-10-31 23:34:44 +08:00
|
|
|
Just ask if this is what you would want. You will be required to have posted
|
2016-08-09 17:39:58 +08:00
|
|
|
several high quality patches first, before you can be granted push access.
|
2010-04-12 17:20:00 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
### How To Make a Patch with git
|
2010-04-12 17:20:00 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
You need to first checkout the repository:
|
2010-04-12 17:20:00 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
git clone https://github.com/curl/curl.git
|
2010-04-12 17:20:00 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
You then proceed and edit all the files you like and you commit them to your
|
|
|
|
local repository:
|
2010-04-12 17:20:00 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
git commit [file]
|
2010-04-12 17:20:00 +08:00
|
|
|
|
2017-01-14 20:01:06 +08:00
|
|
|
As usual, group your commits so that you commit all changes at once that
|
|
|
|
constitute a logical change.
|
2010-03-22 07:34:09 +08:00
|
|
|
|
2021-10-31 23:34:44 +08:00
|
|
|
Once you have done all your commits and you are happy with what you see, you
|
2016-08-09 17:39:58 +08:00
|
|
|
can make patches out of your changes that are suitable for mailing:
|
2002-11-28 22:07:14 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
git format-patch remotes/origin/master
|
2002-11-28 22:07:14 +08:00
|
|
|
|
2022-09-21 05:30:19 +08:00
|
|
|
This creates files in your local directory named `NNNN-[name].patch` for each
|
2016-08-09 17:39:58 +08:00
|
|
|
commit.
|
2002-11-28 22:07:14 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
Now send those patches off to the curl-library list. You can of course opt to
|
|
|
|
do that with the 'git send-email' command.
|
2002-11-28 22:07:14 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
### How To Make a Patch without git
|
2002-11-28 22:07:14 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
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
|
|
|
|
curl community, use GNU diff to generate patches.
|
2002-11-28 22:07:14 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
If you have modified a single file, try something like:
|
2003-03-26 19:48:03 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
diff -u unmodified-file.c my-changed-one.c > my-fixes.diff
|
2003-03-26 19:48:03 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
If you have modified several files, possibly in different directories, you
|
|
|
|
can use diff recursively:
|
2003-03-26 19:48:03 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
diff -ur curl-original-dir curl-modified-sources-dir > my-fixes.diff
|
2003-03-26 19:48:03 +08:00
|
|
|
|
2016-08-09 17:39:58 +08:00
|
|
|
The GNU diff and GNU patch tools exist for virtually all platforms, including
|
2022-09-21 05:30:19 +08:00
|
|
|
all kinds of Unixes and Windows.
|
2020-08-14 14:50:15 +08:00
|
|
|
|
|
|
|
### Useful resources
|
2021-05-19 00:55:55 +08:00
|
|
|
- [Webinar on getting code into cURL](https://www.youtube.com/watch?v=QmZ3W1d6LQI)
|
2022-06-21 22:56:19 +08:00
|
|
|
|
|
|
|
## Update copyright and license information
|
|
|
|
|
|
|
|
There is a CI job called **REUSE compliance / check** that will run on every
|
|
|
|
pull request and commit to verify that the *REUSE state* of all files are
|
|
|
|
still fine.
|
|
|
|
|
|
|
|
This means that all files need to have their license and copyright information
|
|
|
|
clearly stated. Ideally by having the standard curl source code header, with
|
|
|
|
an accurate copyright year range and the SPDX-License-Identifier included. If
|
2022-09-19 23:30:30 +08:00
|
|
|
the header does not work, you can use a smaller header or add the information
|
|
|
|
for a specific file to the `.reuse/dep5` file.
|
2022-06-21 22:56:19 +08:00
|
|
|
|
|
|
|
We update copyright year ranges to end on the year of the most recent change
|
|
|
|
of the individual file.
|
|
|
|
|
|
|
|
You can manually verify the copyright and compliance status by running the
|
|
|
|
`./scripts/copyright.pl` script in the root of the git repository.
|