You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

123 lines
4.5 KiB

  1. Submitting Patch for PHP
  2. ========================
  3. This document describes how to submit a patch for PHP. Since you are
  4. reading this document, you are willing to submit a patch for PHP.
  5. Please keep reading! Submitting a patch for PHP is easy. The hard
  6. part is making it acceptable for inclusion into our repository. :-)
  7. How to create patch?
  8. --------------------
  9. We are working with CVS. You need to get CVS source to create a patch
  10. that we accept. Visit http://www.php.net/anoncvs.php to get CVS
  11. source. You can check out older versions, but make sure you get
  12. the default branch (i.e. Do not use -r option when you check out the
  13. CVS source)
  14. Read CODING_STANDARDS file before you start working.
  15. Now you are ready to create a patch. Modify source to fix a bug in PHP or
  16. add a new feature to PHP. After you finished editing, please test your
  17. patch. Read README.TESTING for testing.
  18. After you finish testing your patch, take diff file using
  19. "cvs diff > your.patch" command.
  20. Read README.TESTING for submitting a test script for your patch. This is
  21. not strictly required, but it is preferred to submit a test script along
  22. with your patch. Making new test script is very easy. It also helps us
  23. to understand what you have been fixed or added to PHP.
  24. Tips for creating patch
  25. -----------------------
  26. If you would like to fix multiple bugs. It is easier for us if you
  27. could create 1 patch for 1 bug, but this is not strictly required.
  28. Note though that you might get little response, if your patch is
  29. too hard to review.
  30. If you would like change/add many lines, it is better to ask module
  31. maintainer and/or php-dev@lists.php.net, or pear-dev@lists.php.net if
  32. you are patching PEAR. Official module maintainers can be found in
  33. EXTENSIONS file in PHP source.
  34. If you are new to CVS (Concurrent Versions System), visit
  35. http://cvshome.org/ for details.
  36. Recommended CVS client settings for creating patch file
  37. ------------------------------------------------------
  38. Recommended ~/.cvsrc file setting is:
  39. ------
  40. cvs -z3
  41. update -d -P
  42. checkout -P
  43. diff -u -b -w -B
  44. ------
  45. diff -u -b -w -B means:
  46. -b Ignore changes in amount of white space.
  47. -B Ignore changes that just insert or delete blank lines.
  48. -u Use the unified output format.
  49. -w Ignore white space when comparing lines.
  50. With this CVS setting, you don't have to worry about adding/deleting
  51. newlines and spaces.
  52. Check list for submitting patch
  53. -------------------------------
  54. - Did you run "make test" to check if your patch didn't break
  55. other features?
  56. - Did you compile PHP with --enable-debug and check php/webserver
  57. error logs when you test your patch?
  58. - Did you build PHP for multi-threaded web servers. (Optional)
  59. - Did you create test script for "make test"? (Recommended)
  60. - Did you check your patch is unified format and it does not
  61. contain white space changes? (If you are not using recommended
  62. cvs setting)
  63. - Did you update CVS source before you take final patch?
  64. - Did you read the patch again?
  65. Where to send your patch?
  66. -------------------------
  67. If you are patching C source, send the patch to php-dev@lists.php.net.
  68. If you are patching a module, you should also send the patch to the
  69. maintainer. Official module maintainers are listed in EXTENSION file
  70. in source.
  71. If you are patching PEAR, send the patch to pear-dev@lists.php.net.
  72. Please add the prefix "[PATCH]" to your email subject and make sure
  73. to include the patch as a MIME attachment even if it is short.
  74. Test scripts should be included in the same email.
  75. Explain what has been fixed/added/changed by your patch.
  76. Finally, add the bug Id(s) which can be closed by your patch, if any.
  77. What happens after you submit your patch
  78. --------------------------------------
  79. If your patch is easy to review and has obviously no side-effects,
  80. it might take up to a few hours until someone commits it.
  81. Because this is a volunteer-driven effort, more complex patches will
  82. require more patience on your side.
  83. If you did not receive any feedback in a few days, please consider
  84. resubmitting the description of your patch, along-side with
  85. these questions:
  86. - Is my patch too hard to review? Because of which factors?
  87. - Should I split it up in multiple parts?
  88. - Are there any unwanted whitespace changes?
  89. What happens when your patch is applied?
  90. ----------------------------------------
  91. Your name will be included together with your email address in the CVS
  92. commit log. If your patch affects end-users, a brief description
  93. and your name might be added to the NEWS file.
  94. Thank you for submitting patch for PHP!