README.SUBMITTING_PATCH 7.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193
  1. Submitting Enhancements and Patches to PHP
  2. ==========================================
  3. This document describes how to submit an enhancement or patch for PHP.
  4. It's easy!
  5. You don't need any login accounts or special access to download,
  6. build, debug and begin submitting PHP or PECL code, tests or
  7. documentation. Once you've followed this README and had several
  8. patches accepted, commit privileges are often quickly granted.
  9. An excellent article to read first is:
  10. http://phpadvent.org/2008/less-whining-more-coding-by-elizabeth-smith
  11. Online Forums
  12. -------------
  13. There are several IRC channels where PHP developers are often
  14. available to discuss questions. They include #php.pecl and #php.doc
  15. on the EFNet network and #php-dev-win on FreeNode.
  16. PHP Patches
  17. -----------
  18. If you are fixing broken functionality in PHP C source code first
  19. create a bug or identify an existing bug at http://bugs.php.net/. A
  20. bug can be used to track the patch progress and prevent your changes
  21. getting lost in the PHP mail archives.
  22. If your change is large then create a Request For Comment (RFC) page
  23. on http://wiki.php.net/rfc, discuss it with the extension maintainer,
  24. and discuss it on the development mail list internals@lists.php.net.
  25. RFC Wiki accounts can be requested on
  26. http://wiki.php.net/start?do=register. PHP extension maintainers can
  27. be found in the EXTENSIONS file in the PHP source. Mail list
  28. subscription is explained on http://www.php.net/mailing-lists.php.
  29. Information on PHP internal C functions is at
  30. http://www.php.net/internals, though this is considered incomplete.
  31. Various external resources can be found on the web. A standard
  32. printed reference is the book "Extending and Embedding PHP" by Sara
  33. Golemon.
  34. Attach the patch to the PHP bug and consider sending a notification
  35. email about the change to internals@lists.php.net. Also CC the
  36. extension maintainer. Explain what has been changed by your patch.
  37. Test scripts should be included.
  38. Please make the mail subject prefix "[PATCH]". If attaching a patch,
  39. ensure it has a file extension of ".txt". This is because only MIME
  40. attachments of type 'text/*' are accepted.
  41. The preferred way to propose PHP patch is sending pull request from
  42. github.
  43. https://github.com/php/php-src
  44. Fork the official PHP repository and send a pull request. A
  45. notification will be sent to the pull request mailing list. Sending a
  46. note to PHP Internals list (internals@lists.php.net) may help getting
  47. more feedback and quicker turnaround. You can also add pull requests
  48. to bug reports at http://bugs.php.net/.
  49. PHP Documentation Patches
  50. -------------------------
  51. If you are fixing incorrect PHP documentation first create a bug or
  52. identify an existing bug at http://bugs.php.net/. A bug can be used
  53. to track the patch progress and prevent your changes getting lost in
  54. the PHP mail archives.
  55. If your change is large, then first discuss it with the mail list
  56. phpdoc@lists.php.net. Subscription is explained on
  57. http://www.php.net/mailing-lists.php.
  58. Information on contributing to PHP documentation is at
  59. http://php.net/dochowto and http://wiki.php.net/doc/howto
  60. Attach the patch to the PHP bug and consider sending a notification
  61. email about the change to phpdoc@lists.php.net. Explain what has been
  62. fixed/added/changed by your patch.
  63. Please make the mail subject prefix "[PATCH]". Include the bug id(s)
  64. which can be closed by your patch. If attaching a patch, ensure it
  65. has a file extension of ".txt". This is because only MIME attachments
  66. of type 'text/*' are accepted.
  67. PECL Extension Patches: http://pecl.php.net/
  68. --------------------------------------------
  69. If you are fixing broken functionality in a PECL extension then create
  70. a bug or identify an existing bug at http://bugs.php.net/. A bug
  71. can be used to track the patch progress and prevent your changes
  72. getting lost in the PHP mail archives.
  73. If your change is large then create a Request For Comment (RFC) page
  74. on http://wiki.php.net/rfc, discuss it with the extension maintainer,
  75. and discuss it on the development mail list pecl-dev@lists.php.net.
  76. PECL mail list subscription is explained on
  77. http://pecl.php.net/support.php. RFC Wiki accounts can be requested
  78. on http://wiki.php.net/start?do=register
  79. Information on PHP internal C functions is at
  80. http://www.php.net/internals, though this is considered incomplete.
  81. Various external resources can be found on the web. A standard
  82. printed reference is the book "Extending and Embedding PHP" by Sara
  83. Golemon.
  84. Update any open bugs and add a link to the source of your patch. Send
  85. the patch or pointer to the bug to pecl-dev@lists.php.net. Also CC
  86. the extension maintainer. Explain what has been changed by your
  87. patch. Test scripts should be included.
  88. Please make the mail subject prefix "[PATCH] ...". Include the patch
  89. as an attachment with a file extension of ".txt". This is because
  90. only MIME attachments of type 'text/*' are accepted.
  91. PEAR Package Patches: http://pear.php.net/
  92. ------------------------------------------
  93. Information on contributing to PEAR is available at
  94. http://pear.php.net/manual/en/developers-newmaint.php and
  95. http://pear.php.net/manual/en/guide-developers.php
  96. How to create your PHP, PHP Documentation or PECL patch
  97. -------------------------------------------------------
  98. PHP and most PECL packages use Git for revision control. Some PECL
  99. packages use Subversion (SVN) Read http://www.php.net/git.php for help
  100. on using Git to get and build PHP source code. We recommend to look
  101. at our workflow on https://wiki.php.net/vcs/gitworkflow and our FAQ
  102. https://wiki.php.net/vcs/gitfaq.
  103. Generally we ask that bug fix patches work on the current stable PHP
  104. development branches and on "master". New PHP features only need to
  105. work on "master".
  106. Read CODING_STANDARDS before you start working.
  107. After modifying the source see README.TESTING and
  108. http://qa.php.net/write-test.php for how to test. Submitting test
  109. scripts helps us to understand what functionality has changed. It is
  110. important for the stability and maintainability of PHP that tests are
  111. comprehensive.
  112. After testing is finished, create a patch file using the command:
  113. git diff > your_patch.txt
  114. For ease of review and later troubleshooting, submit individual
  115. patches for each bug or feature.
  116. Checklist for submitting your PHP or PECL code patch
  117. ----------------------------------------------------
  118. - Update git source just before running your final 'diff' and
  119. before testing.
  120. - Add in-line comments and/or have external documentation ready.
  121. Use only "/* */" style comments, not "//".
  122. - Create test scripts for use with "make test".
  123. - Run "make test" to check your patch doesn't break other features.
  124. - Rebuild PHP with --enable-debug (which will show some kinds of
  125. memory errors) and check the PHP and web server error logs after
  126. running your PHP tests.
  127. - Rebuild PHP with --enable-maintainer-zts to check your patch
  128. compiles on multi-threaded web servers.
  129. - Review the patch once more just before submitting it.
  130. What happens after submitting your PHP, PHP Documentation or PECL patch
  131. -----------------------------------------------------------------------
  132. If your patch is easy to review and obviously has no side-effects,
  133. it might be committed relatively quickly.
  134. Because PHP is a volunteer-driven effort more complex patches will
  135. require patience on your side. If you do not receive feedback in a
  136. few days, consider resubmitting the patch. Before doing this think
  137. about these questions:
  138. - Did I send the patch to the right mail list?
  139. - Did I review the mail list archives to see if these kind of
  140. changes had been discussed before?
  141. - Did I explain my patch clearly?
  142. - Is my patch too hard to review? Because of what factors?
  143. What happens when your PHP or PECL patch is applied
  144. ---------------------------------------------------
  145. Your name will likely be included in the Git commit log. If your
  146. patch affects end users, a brief description and your name might be
  147. added to the NEWS file.
  148. Thank you for patching PHP!