summaryrefslogtreecommitdiff
path: root/README.SUBMITTING_PATCH
diff options
context:
space:
mode:
Diffstat (limited to 'README.SUBMITTING_PATCH')
-rw-r--r--README.SUBMITTING_PATCH121
1 files changed, 0 insertions, 121 deletions
diff --git a/README.SUBMITTING_PATCH b/README.SUBMITTING_PATCH
deleted file mode 100644
index 3b30d8b928..0000000000
--- a/README.SUBMITTING_PATCH
+++ /dev/null
@@ -1,121 +0,0 @@
-Submitting Patch for PHP
-========================
-
-This document describes how to submit a patch for PHP. Since you are
-reading this document, you are willing to submit a patch for PHP.
-Please keep reading! Submitting a patch for PHP is easy. The hard
-part is making it acceptable for inclusion into our repository. :-)
-
-How to create patch?
---------------------
-We are working with CVS. You need to get CVS source to create a patch
-that we accept. Visit http://www.php.net/anoncvs.php to get CVS
-source. You can check out older versions, but make sure you get
-the default branch (i.e. Do not use -r option when you check out the
-CVS source)
-
-Read CODING_STANDARDS file before you start working.
-
-Now you are ready to create a patch. Modify source to fix a bug in PHP or
-add a new feature to PHP. After you finished editing, please test your
-patch. Read README.TESTING for testing.
-
-After you finish testing your patch, take diff file using
-"cvs diff > your.patch" command.
-
-Read README.TESTING for submitting a test script for your patch. This is
-not strictly required, but it is preferred to submit a test script along
-with your patch. Making new test script is very easy. It also helps us
-to understand what you have been fixed or added to PHP.
-
-
-Tips for creating patch
------------------------
-If you would like to fix multiple bugs. It is easier for us if you
-could create 1 patch for 1 bug, but this is not strictly required.
-Note though that you might get little response, if your patch is
-too hard to review.
-
-If you would like change/add many lines, it is better to ask module
-maintainer and/or php-dev@lists.php.net, or pear-dev@lists.php.net if
-you are patching PEAR. Official module maintainers can be found in
-EXTENSIONS file in PHP source.
-
-If you are new to CVS (Concurrent Versions System), visit
-http://cvshome.org/ for details.
-
-
-Recommended CVS client settings for creating patch file
-------------------------------------------------------
-Recommended ~/.cvsrc file setting is:
-------
-cvs -z3
-update -d -P
-checkout -P
-diff -u
-
-------
-diff -u means:
- -u Use the unified output format.
-
-With this CVS setting, you don't have to worry about adding/deleting
-newlines and spaces.
-
-
-Check list for submitting patch
--------------------------------
- - Did you run "make test" to check if your patch didn't break
- other features?
- - Did you compile PHP with --enable-debug and check php/webserver
- error logs when you test your patch?
- - Did you build PHP for multi-threaded web servers. (Optional)
- - Did you create test script for "make test"? (Recommended)
- - Did you check your patch is unified format and it does not
- contain white space changes? (If you are not using recommended
- cvs setting)
- - Did you update CVS source before you take final patch?
- - Did you read the patch again?
-
-
-Where to send your patch?
--------------------------
-If you are patching C source, send the patch to php-dev@lists.php.net.
-If you are patching a module, you should also send the patch to the
-maintainer. Official module maintainers are listed in EXTENSION file
-in source.
-
-If you are patching PEAR, send the patch to pear-dev@lists.php.net.
-
-Please add the prefix "[PATCH]" to your email subject and make sure
-to include the patch as a MIME attachment even if it is short.
-Test scripts should be included in the same email.
-Explain what has been fixed/added/changed by your patch.
-
-Finally, add the bug Id(s) which can be closed by your patch, if any.
-
-
-What happens after you submit your patch
---------------------------------------
-If your patch is easy to review and has obviously no side-effects,
-it might take up to a few hours until someone commits it.
-
-Because this is a volunteer-driven effort, more complex patches will
-require more patience on your side.
-
-If you did not receive any feedback in a few days, please consider
-resubmitting the description of your patch, along-side with
-these questions:
-
-- Is my patch too hard to review? Because of which factors?
-- Should I split it up in multiple parts?
-- Are there any unwanted whitespace changes?
-
-
-What happens when your patch is applied?
-----------------------------------------
-Your name will be included together with your email address in the CVS
-commit log. If your patch affects end-users, a brief description
-and your name might be added to the NEWS file.
-
-
-Thank you for submitting patch for PHP!