Imported Upstream version 7.44.0

[platform/upstream/curl.git] / docs / CONTRIBUTE

diff --git a/docs/CONTRIBUTE b/docs/CONTRIBUTE
index 83fa420..c6ea977 100644 (file)
--- a/docs/CONTRIBUTE
+++ b/docs/CONTRIBUTE
@@ -34,7 +34,7 @@
  3.3 How To Make a Patch without git
  3.4 How to get your changes into the main sources
  3.5 Write good commit messages
- 3.6 Please don't send pull requests
+ 3.6 About pull requests
 
 ==============================================================================
 
@@ -52,6 +52,10 @@
 
  We also hang out on IRC in #curl on irc.freenode.net
 
+ If you're at all interested in the code side of things, consider clicking
+ 'watch' on the curl repo at github to get notified on pull requests and new
+ issues posted there.
+
 1.2. License
 
  When contributing with code, you agree to put your changes and new code under
@@ -78,10 +82,10 @@
 
 1.3 What To Read
 
- Source code, the man pages, the INTERNALS document, TODO, KNOWN_BUGS, the
- most recent CHANGES. Just lurking on the curl-library mailing list is gonna
- give you a lot of insights on what's going on right now. Asking there is a
- good idea too.
+ Source code, the man pages, the INTERNALS document, TODO, KNOWN_BUGS and the
+ most recent changes in the git log. Just lurking on the curl-library mailing
+ list is gonna give you a lot of insights on what's going on right now. Asking
+ there is a good idea too.
 
 2. cURL Coding Standards
 
@@ -199,7 +203,7 @@
 
  You need to first checkout the repository:
 
-     git clone git://github.com/bagder/curl.git
+     git clone https://github.com/bagder/curl.git
 
  You then proceed and edit all the files you like and you commit them to your
  local repository:
@@ -241,8 +245,8 @@
 
  For unix-like operating systems:
 
-     http://www.gnu.org/software/patch/patch.html
-     http://www.gnu.org/directory/diffutils.html
+     https://savannah.gnu.org/projects/patch/
+     https://www.gnu.org/software/diffutils/
 
  For Windows:
 
@@ -288,27 +292,15 @@
  and make sure that you have your own user and email setup correctly in git
  before you commit
 
-3.6 Please don't send pull requests
+3.6 About pull requests
 
  With git (and especially github) it is easy and tempting to send a pull
- request to one or more people in the curl project to have changes merged this
- way instead of mailing patches to the curl-library mailing list.
-
- We don't like that. We want them mailed for these reasons:
-
- - Peer review. Anyone and everyone on the list can review, comment and
-   improve on the patch. Pull requests limit this ability.
-
- - Anyone can merge the patch into their own trees for testing and those who
-   have push rights can push it to the main repo. It doesn't have to be anyone
-   the patch author knows beforehand.
-
- - Commit messages can be tweaked and changed if merged locally instead of
-   using github. Merges directly on github requires the changes to be perfect
-   already, which they seldom are.
+ request to the curl project to have changes merged this way instead of
+ mailing patches to the curl-library mailing list.
 
- - Merges on github prevents rebases and even enforces --no-ff which is a git
-   style we don't otherwise use in the project
+ 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!
 
- However: once patches have been reviewed and deemed fine on list they are
- perfectly OK to be pulled from a published git tree.
+ We will continue to avoid using github's merge tools to make the history
+ linear and to make sure commits follow our style guidelines.