← Back to branch summary

~ubuntu-branches/ubuntu/hardy/php5/hardy-updates

« back to all changes in this revision

Viewing changes to README.SUBMITTING_PATCH

  • Committer: Bazaar Package Importer
  • Author(s): Adam Conrad
  • Date: 2005-10-09 03:14:32 UTC
  • Revision ID: james.westby@ubuntu.com-20051009031432-kspik3lobxstafv9
Tags: upstream-5.0.5
Import upstream version 5.0.5

Show diffs side-by-side

added added

removed removed

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