Add pecl mail list

README.SUBMITTING_PATCH

@@ -12,17 +12,20 @@ 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.
 
-If your code change is large then discuss it with the extension
-maintainer and/or internals@lists.php.net (or pear-dev@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
-
-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
+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
+internals@lists.php.net mail list to discuss changes to the base PHP
+code. Use pecl-dev@lists.php.net for changes to code that is only
+available from PECL (http://pecl.php.net/). Use pear-dev@lists.php.net
+for PEAR modules (http://pear.php.net/). Mail list subscription is
+explained on http://www.php.net/mailing-lists.php.
+
+If a PHP or PECL patch affects user-functionality or makes significant
+internal changes then create a simple RFC on http://wiki.php.net/rfc
+before starting discussion. 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
 
 
 How to create your patch
@@ -39,12 +42,12 @@ development branch and on "trunk".
 Read CODING_STANDARDS before you start working.
 
 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.
+http://qa.php.net/write-test.php 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
+comprehensive.
 
-After testing is finished, create a diff file using the command:
+After testing is finished, create a patch file using the command:
 
   svn diff > your_patch.txt
 
@@ -54,8 +57,8 @@ patches for each bug or feature.
 
 Checklist for submitting your patch
 -----------------------------------
- - Update SVN source just before creating your final 'diff' and
-   running tests.
+ - 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
@@ -69,25 +72,30 @@ Checklist for submitting your patch
 
 Where to send your patch
 ------------------------
-If you are patching C source then email the patch to
-internals@lists.php.net and/or to the extension maintainer (see
-EXTENSIONS).
+If you are patching PHP C source then email the patch to
+internals@lists.php.net
+
+If you patching a PECL extension then send the patch to
+pecl-dev@lists.php.net
+
+If you are patching PEAR then send the patch to
+pear-dev@lists.php.net
 
-If you are patching PEAR then send the patch to pear-dev@lists.php.net.
+The mail can be CC'd to the extension maintainer (see EXTENSIONS).
 
-Please make the subject prefix "[PATCH]".  
+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'.
+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.
 
 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.
+Finally, update any open bugs and add a link to the source of your
+patch.
 
 
 What happens after you submit your patch