Imported Upstream version 5.0.4upstream/5.0.4

1 files changed, 126 insertions, 0 deletions

diff --git a/README.SUBMITTING_PATCH b/README.SUBMITTING_PATCH
new file mode 100644
index 000000000..04847d79c
--- /dev/null
+++ b/README.SUBMITTING_PATCH
@@ -0,0 +1,126 @@
+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 internals@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 the PHP and
+   web server 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 internals@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. 
+
+NOTE: only MIME attachments of type 'text/*' are accepted. The
+      easiest way to accomplish this, is to make the extension
+      '.txt'.
+
+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!