sixd                                     Thu, 05 Nov 2009 23:03:28 +0000

Revision: http://svn.php.net/viewvc?view=revision&revision=290363

Log:
Update and fix grammar

Changed paths:
    U   php/php-src/branches/PHP_5_3/README.SUBMITTING_PATCH
    U   php/php-src/trunk/README.SUBMITTING_PATCH

Modified: php/php-src/branches/PHP_5_3/README.SUBMITTING_PATCH
===================================================================
--- php/php-src/branches/PHP_5_3/README.SUBMITTING_PATCH	2009-11-05 22:44:02 UTC (rev 290362)
+++ php/php-src/branches/PHP_5_3/README.SUBMITTING_PATCH	2009-11-05 23:03:28 UTC (rev 290363)
@@ -1,106 +1,119 @@
 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. :-)
+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
-http://www.php.net/svn.php 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.

-Read CODING_STANDARDS file before you start working.
+Prework
+-------
+If you are fixing broken functionality then create a bug or identify
+an existing bug at http://bugs.php.net/. This can be used to track
+the patch progress and prevent your changes getting lost in the PHP
+mail archives.

-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.
+If your code change is large then discuss it with the extension
+maintainer and/or intern...@lists.php.net (or pear-...@lists.php.net
+if you are patching PEAR) before starting work. Maintainers can be
+found in the EXTENSIONS file in the PHP source. Mail list subscription
+is explained on http://www.php.net/mailing-lists.php

-After you finish testing your patch, take diff file using
-"svn diff > your.patch" command.
+If your patch affects user-functionality or makes significant internal
+changes to PHP then create a simple RFC on http://wiki.php.net/rfc.
+This RFC can be used for initial discussion and later for
+documentation. Wiki accounts can be requested on
+http://wiki.php.net/start?do=register

-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.

+How to create your patch
+------------------------
+PHP uses Subversion (SVN) for revision control. Read
+http://www.php.net/svn.php for help on using SVN to get and build PHP
+source code. We recommend using a Sparse Directory checkout described
+in http://wiki.php.net/vcs/svnfaq. If you are new to SVN, read
+http://svnbook.red-bean.com.

-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.
+Generally we ask that patches work on the current stable PHP
+development branch and on "trunk".

-If you would like change/add many lines, it is better to ask module
-maintainer and/or intern...@lists.php.net, or pear-...@lists.php.net if
-you are patching PEAR. Official module maintainers can be found in
-EXTENSIONS file in PHP source.
+Read CODING_STANDARDS before you start working.

-If you are new to SVN (Subversion), visit
-http://svnbook.red-bean.com/ for details.
+After modifying the source see README.TESTING and
+http://qa.php.net/write-test.php for how to test your
+change. Submitting test scripts helps us to understand what
+functionality has changed. It is important for the stability and
+maintainability of PHP that tests are comprehensive.

+After testing is finished, create a diff file using the command:

-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?
+  svn diff > your_patch.txt

+For ease of review and later troubleshooting, submit individual
+patches for each bug or feature.

-Where to send your patch?
--------------------------
-If you are patching C source, send the patch to intern...@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-...@lists.php.net.
+Checklist for submitting your patch
+-----------------------------------
+ - Update SVN source just before creating your final 'diff' and
+   running tests.
+ - 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.

-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'.
+Where to send your patch
+------------------------
+If you are patching C source then email the patch to
+intern...@lists.php.net and/or to the extension maintainer (see
+EXTENSIONS).

-Test scripts should be included in the same email.
-Explain what has been fixed/added/changed by your patch.
+If you are patching PEAR then send the patch to pear-...@lists.php.net.

-Finally, add the bug Id(s) which can be closed by your patch, if any.
+Please make the subject prefix "[PATCH]".

+Include the patch as a 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.
+
+Include the bug id(s) which can be closed by your patch.
+
+Finally, if there is a bug open, add a link in the bug report to the
+source of your patch.
+
+
 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 your patch is easy to review and obviously has no side-effects,
+it might be committed relatively quickly.

-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
+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.

+Commit privileges are often granted to people who have had several
+patches accepted.

-Thank you for submitting patch for PHP!
+Thank you for patching PHP!

Modified: php/php-src/trunk/README.SUBMITTING_PATCH
===================================================================
--- php/php-src/trunk/README.SUBMITTING_PATCH	2009-11-05 22:44:02 UTC (rev 290362)
+++ php/php-src/trunk/README.SUBMITTING_PATCH	2009-11-05 23:03:28 UTC (rev 290363)
@@ -1,106 +1,119 @@
 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. :-)
+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
-http://www.php.net/svn.php 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.

-Read CODING_STANDARDS file before you start working.
+Prework
+-------
+If you are fixing broken functionality then create a bug or identify
+an existing bug at http://bugs.php.net/. This can be used to track
+the patch progress and prevent your changes getting lost in the PHP
+mail archives.

-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.
+If your code change is large then discuss it with the extension
+maintainer and/or intern...@lists.php.net (or pear-...@lists.php.net
+if you are patching PEAR) before starting work. Maintainers can be
+found in the EXTENSIONS file in the PHP source. Mail list subscription
+is explained on http://www.php.net/mailing-lists.php

-After you finish testing your patch, take diff file using
-"svn diff > your.patch" command.
+If your patch affects user-functionality or makes significant internal
+changes to PHP then create a simple RFC on http://wiki.php.net/rfc.
+This RFC can be used for initial discussion and later for
+documentation. Wiki accounts can be requested on
+http://wiki.php.net/start?do=register

-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.

+How to create your patch
+------------------------
+PHP uses Subversion (SVN) for revision control. Read
+http://www.php.net/svn.php for help on using SVN to get and build PHP
+source code. We recommend using a Sparse Directory checkout described
+in http://wiki.php.net/vcs/svnfaq. If you are new to SVN, read
+http://svnbook.red-bean.com.

-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.
+Generally we ask that patches work on the current stable PHP
+development branch and on "trunk".

-If you would like change/add many lines, it is better to ask module
-maintainer and/or intern...@lists.php.net, or pear-...@lists.php.net if
-you are patching PEAR. Official module maintainers can be found in
-EXTENSIONS file in PHP source.
+Read CODING_STANDARDS before you start working.

-If you are new to SVN (Subversion), visit
-http://svnbook.red-bean.com/ for details.
+After modifying the source see README.TESTING and
+http://qa.php.net/write-test.php for how to test your
+change. Submitting test scripts helps us to understand what
+functionality has changed. It is important for the stability and
+maintainability of PHP that tests are comprehensive.

+After testing is finished, create a diff file using the command:

-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?
+  svn diff > your_patch.txt

+For ease of review and later troubleshooting, submit individual
+patches for each bug or feature.

-Where to send your patch?
--------------------------
-If you are patching C source, send the patch to intern...@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-...@lists.php.net.
+Checklist for submitting your patch
+-----------------------------------
+ - Update SVN source just before creating your final 'diff' and
+   running tests.
+ - 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.

-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'.
+Where to send your patch
+------------------------
+If you are patching C source then email the patch to
+intern...@lists.php.net and/or to the extension maintainer (see
+EXTENSIONS).

-Test scripts should be included in the same email.
-Explain what has been fixed/added/changed by your patch.
+If you are patching PEAR then send the patch to pear-...@lists.php.net.

-Finally, add the bug Id(s) which can be closed by your patch, if any.
+Please make the subject prefix "[PATCH]".

+Include the patch as a 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.
+
+Include the bug id(s) which can be closed by your patch.
+
+Finally, if there is a bug open, add a link in the bug report to the
+source of your patch.
+
+
 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 your patch is easy to review and obviously has no side-effects,
+it might be committed relatively quickly.

-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
+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.

+Commit privileges are often granted to people who have had several
+patches accepted.

-Thank you for submitting patch for PHP!
+Thank you for patching PHP!
-- 
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to