Browse files

Imported Upstream version 5.3.2

  • Loading branch information...
1 parent c852c28 commit 855a09f4eded707941180c9d90acd17c25e29447 @oerdnj oerdnj committed Mar 9, 2010
Showing 1,701 changed files with 64,078 additions and 40,972 deletions.
@@ -79,29 +79,25 @@ PHP_TEST_SHARED_EXTENSIONS = ` \
. $$i; $(top_srcdir)/build/shtool echo -n -- " -d $(ZEND_EXT_TYPE)=$(top_builddir)/modules/$$dlname"; \
done; \
+PHP_DEPRECATED_DIRECTIVES_REGEX = '^(define_syslog_variables|register_(globals|long_arrays)?|safe_mode|magic_quotes_(gpc|runtime|sybase)?|(zend_)?extension(_debug)?(_ts)?)[\t\ ]*='
test: all
-@if test ! -z "$(PHP_EXECUTABLE)" && test -x "$(PHP_EXECUTABLE)"; then \
- TEST_PHP_SRCDIR=$(top_srcdir) \
- CC="$(CC)" \
- $(PHP_EXECUTABLE) $(PHP_TEST_SETTINGS) $(top_srcdir)/run-tests.php -d extension_dir=modules/ $(PHP_TEST_SHARED_EXTENSIONS) tests/; \
- elif test ! -z "$(SAPI_CLI_PATH)" && test -x "$(SAPI_CLI_PATH)"; then \
- INI_FILE=`$(top_builddir)/$(SAPI_CLI_PATH) -d 'display_errors=stderr' -r 'echo php_ini_loaded_file();' 2> /dev/null`; \
+ INI_FILE=`$(PHP_EXECUTABLE) -d 'display_errors=stderr' -r 'echo php_ini_loaded_file();' 2> /dev/null`; \
if test "$$INI_FILE"; then \
- $(EGREP) -v '^(magic_quotes_(gpc|runtime|sybase)?|(zend_)?extension(_debug)?(_ts)?)[\t\ ]*=' "$$INI_FILE" > $(top_builddir)/tmp-php.ini; \
+ $(EGREP) -h -v $(PHP_DEPRECATED_DIRECTIVES_REGEX) "$$INI_FILE" > $(top_builddir)/tmp-php.ini; \
else \
echo > $(top_builddir)/tmp-php.ini; \
fi; \
- INI_SCANNED_PATH=`$(top_builddir)/$(SAPI_CLI_PATH) -d 'display_errors=stderr' -r '$$a = explode(",\n", trim(php_ini_scanned_files())); echo $$a[0];' 2> /dev/null`; \
+ INI_SCANNED_PATH=`$(PHP_EXECUTABLE) -d 'display_errors=stderr' -r '$$a = explode(",\n", trim(php_ini_scanned_files())); echo $$a[0];' 2> /dev/null`; \
if test "$$INI_SCANNED_PATH"; then \
INI_SCANNED_PATH=`$(top_srcdir)/build/shtool path -d $$INI_SCANNED_PATH`; \
- $(EGREP) -h -v '^(magic_quotes_(gpc|runtime|sybase)?|(zend_)?extension(_debug)?(_ts)?)[\t\ ]*=' "$$INI_SCANNED_PATH"/*.ini >> $(top_builddir)/tmp-php.ini; \
+ $(EGREP) -h -v $(PHP_DEPRECATED_DIRECTIVES_REGEX) "$$INI_SCANNED_PATH"/*.ini >> $(top_builddir)/tmp-php.ini; \
fi; \
- TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) \
TEST_PHP_SRCDIR=$(top_srcdir) \
CC="$(CC)" \
- $(top_builddir)/$(SAPI_CLI_PATH) -n -c $(top_builddir)/tmp-php.ini $(PHP_TEST_SETTINGS) $(top_srcdir)/run-tests.php -n -c $(top_builddir)/tmp-php.ini -d extension_dir=$(top_builddir)/modules/ $(PHP_TEST_SHARED_EXTENSIONS) $(TESTS); \
+ $(PHP_EXECUTABLE) -n -c $(top_builddir)/tmp-php.ini $(PHP_TEST_SETTINGS) $(top_srcdir)/run-tests.php -n -c $(top_builddir)/tmp-php.ini -d extension_dir=$(top_builddir)/modules/ $(PHP_TEST_SHARED_EXTENSIONS) $(TESTS); \
else \
echo "ERROR: Cannot run tests without CLI sapi."; \
287 NEWS

Large diffs are not rendered by default.

Oops, something went wrong.
@@ -100,9 +100,9 @@ Derick) run the following commands for you:
``sudo -u ezmlm ezmlm-sub ~ezmlm/primary-qa-tester/mod moderator-email-address``
-3. Update the MD5 sums in ``qaweb/include/rc-md5sums.txt`` (no empty lines).
+3. Update the MD5 sums in ``web/qa/trunk/include/rc-md5sums.txt`` (no empty lines).
-4. Update in ``qaweb/include/release-qa.php`` constants with the new RC and
+4. Update in ``web/qa/trunk/include/release-qa.php`` constants with the new RC and
commit this.
a. ``$BUILD_TEST_RELEASES`` = array("4.4.7RC1", "5.2.2RC1")
@@ -111,7 +111,7 @@ commit this.
c. ``$RELEASE_PROCESS`` = array(4 => true, 5 => true)
-1. Update in ``php-bugs-web/include/`` the ``show_version_option``
+1. Update in ``php-bugs/trunk/include/`` the ``show_version_option``
function to include the new RC and commit.
2. Update ``phpweb/include/`` (x=major version number)
@@ -1,106 +1,136 @@
-Submitting Patch for PHP
+Submitting Patches to 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. :-)
+This document describes how to submit a patch for PHP. Creating a
+patch for PHP is easy!
-How to create patch?
-We use Subversion (SVN) for revision control. You need to get the
-source from SVN in order to create a patch. Read
- for help on using SVN. You can check out
-older branches, but make sure you get trunk as well and make your
-patch work there.
+You don't need any login accounts or special access to download,
+build, debug and begin submitting PHP code, tests or documentation for
+inclusion in PHP. Once you've followed this README and had several
+patches accepted, PHP commit privileges are often quickly granted.
-Read CODING_STANDARDS file before you start working.
+An excellent article to read first is:
-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
-"svn diff > your.patch" command.
+If you are fixing broken functionality then create a bug or identify
+an existing bug at This can be used to track
+the patch progress and prevent your changes getting lost in the PHP
+mail archives.
-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.
+If your code change is large then first discuss it with the extension
+maintainer and/or a development mail list. Extension maintainers can
+be found in the EXTENSIONS file in the PHP source. Use the mail list to discuss changes to the base PHP
+code. Use for changes to code that is only
+available from PECL ( Use
+for PEAR modules ( Mail list subscription is
+explained on
+If a PHP or PECL patch affects user-functionality or makes significant
+internal changes then create a simple RFC on
+before starting discussion. This RFC can be used for initial
+discussion and later for documentation. Wiki accounts can be requested
-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.
+There are several IRC channels where PHP developers are often
+available to discuss questions. They include #php.pecl on the EFNet
+network and #php-dev-win on FreeNode.
-If you would like change/add many lines, it is better to ask module
-maintainer and/or, or if
-you are patching PEAR. Official module maintainers can be found in
-EXTENSIONS file in PHP source.
-If you are new to SVN (Subversion), visit
- for details.
+How to create your patch
+PHP uses Subversion (SVN) for revision control. Read
+ for help on using SVN to get and build PHP
+source code. We recommend using a Sparse Directory checkout described
+in If you are new to SVN, read
+Generally we ask that patches work on the current stable PHP
+development branch and on "trunk".
-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 update SVN source before you take final patch?
- - Did you read the patch again?
+Read CODING_STANDARDS before you start working.
+After modifying the source see README.TESTING and
+ for how to test. Submitting test
+scripts helps us to understand what functionality has changed. It is
+important for the stability and maintainability of PHP that tests are
-Where to send your patch?
-If you are patching C source, send the patch to
-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.
+After testing is finished, create a patch file using the command:
-If you are patching PEAR, send the patch to
+ svn diff > your_patch.txt
-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.
+For ease of review and later troubleshooting, submit individual
+patches for each bug or feature.
-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.
+Checklist for submitting your patch
+ - Update SVN source just before running your final 'diff' and
+ before testing.
+ - Run "make test" to check your patch doesn't break other features.
+ - Rebuild PHP with --enable-debug (which will show some kinds of
+ memory errors) and check the PHP and web server error logs after
+ running the PHP tests.
+ - Rebuild PHP with --enable-maintainer-zts to check your patch compiles
+ on multi-threaded web servers.
+ - Create test scripts for use with "make test".
+ - Add in-line comments and/or have external documentation ready.
+ - Review the patch once more just before submitting it.
-Finally, add the bug Id(s) which can be closed by your patch, if any.
+Where to send your patch
+If you are patching PHP C source then email the patch to
-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.
+If you patching a PECL extension then send the patch to
+If you are patching PEAR then send the patch to
+The mail can be CC'd to the extension maintainer (see EXTENSIONS).
+Please make the subject prefix "[PATCH]".
+Include the patch as an attachment. Note: only MIME attachments of
+type 'text/*' are accepted. The easiest way to accomplish this is to
+make the file extension '.txt'.
+Explain what has been fixed/added/changed by your patch. Test scripts
+should be included in the email.
-Because this is a volunteer-driven effort, more complex patches will
-require more patience on your side.
+Include the bug id(s) which can be closed by your patch.
-If you did not receive any feedback in a few days, please consider
-resubmitting the description of your patch, along-side with
+Finally, update any open bugs and add a link to the source of your
+What happens after you submit your patch
+If your patch is easy to review and obviously has no side-effects,
+it might be committed relatively quickly.
+Because PHP is a volunteer-driven effort more complex patches will
+require patience on your side. If you do not receive feedback in a few
+days, consider resubmitting the patch. Before doing this think about
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?
+ - Did I review the mail list archives to see if these kind of
+ changes had been discussed before?
+ - Did I explain my patch clearly?
+ - Is my patch too hard to review? Because of which factors?
+ - Are there any unwanted white space changes?
-What happens when your patch is applied?
+What happens when your patch is applied
Your name will be included together with your email address in the SVN
-commit log. If your patch affects end-users, a brief description
+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!
+Thank you for patching PHP!
Oops, something went wrong.

0 comments on commit 855a09f

Please sign in to comment.