forked from php/php-src
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.CVS-RULES
114 lines (79 loc) · 4.71 KB
/
README.CVS-RULES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
This is the first file you should be reading after you get your CVS account.
We'll assume you're basically familiar with CVS, but feel free to post
your questions on the mailing list.
PHP is developed through the efforts of a large number of people.
Collaboration is a Good Thing(tm), and CVS lets us do this. Thus, following
some basic rules with regards to CVS usage will:
a. Make everybody happier, especially those responsible for maintaining
the CVS itself.
b. Keep the changes consistently well documented and easily trackable.
c. Prevent some of those 'Oops' moments.
d. Increase the general level of good will on planet Earth.
Having said that, here are the organizational rules:
1. Respect other people working on the project.
2. Discuss any significant changes on the list before committing.
3. Look at EXTENSIONS file to see who is the primary maintainer of
the code you want to contribute to.
4. If you "strongly disagree" about something another person did, don't
start fighting publicly - take it up in private email.
5. If you don't know how to do something, ask first!
6. Test your changes before committing them. We mean it. Really.
The next few rules are more of a technical nature.
1. DO NOT TOUCH ChangeLog! It is automagically updated from the commit
messages every day. Woe be to those who attempt to mess with it.
2. All news updates intended for public viewing, such as new features,
bug fixes, improvements, etc., should go into the NEWS file. Also see
the note below about automatically updating NEWS in your commit message.
3. Do not commit multiple file and dump all messages in one commit. If you
modified several unrelated files, commit each group separately and
provide a nice commit message for each one. See example below.
4. Do write your commit message in such a way that it makes sense even
without the corresponding diff. One should be able to look at it, and
immediately know what was modified. Definitely include the function name
in the message as shown below.
5. In your commit messages, keep each line shorter than 80 characters. And
try to align your lines vertically, if they wrap. It looks bad otherwise.
6. If you modified a function that is callable from PHP, prepend PHP to
the function name as shown below.
The format of the commit messages is pretty simple.
If a line begins with #, it is taken to be a comment and will not appear
in the ChangeLog. If the line begins with @, it will be redirected to the
NEWS file. Everything else goes into the ChangeLog.
It is important to note that if your comment or news logline spans multiple
lines, you have to put # or @ at the beginning of _every_ such line. Every
entry in NEWS has to have a name after it, so if you did it with someone's
help, put both your names there. Your name WILL NOT be automatically put
at the end of the NEWS entry - so, please provide it yourself.
Example. Say you modified two files, datetime.c and string.c. In datetime.c
you added a new format option for date() function, and in string.c you fixed
a memory leak in php_trim(). Don't commit both of these at once. Commit them
separately and try to make sure your commit messages look something like the
following.
For datetime.c:
(PHP date) Added new 'K' format modifier for printing out number of
days until New Year's Eve.
@- Added new 'K' format modifier that will output the number of days
@ until New Year's Eve. (Bob)
For string.c:
(php_trim) Fixed a memory leak resulting from improper use of zval_dtor().
# Man, that thing was leaking all over the place!
@- Memory leak in trim() function has finally been fixed. (Bob)
The lines above marked with @ will go into NEWS file automagically, and the
# lines will be omitted from the ChangeLog. Alternatively, you might want
to modify NEWS file directly and not use the @ lines.
If you fix some bugs, you should note the bug ID numbers in your
commit message. Bug ID should be prefixed by "#" for easier access to
bug report when developers are browsing CVS via. LXR or Bonsai.
Example:
Fixed pgsql notice handler double free crash bug. Bug #14016
@ Fixed pgsql notice handler double free crash bug. Bug #14016
If you don't see your messages in ChangeLog and NEWS right away, don't worry!
These files are updated once a day, so your stuff will not show up until
somewhat later. Don't go adding stuff to NEWS by hand if you already put @
lines in the commit message.
You can use LXR (http://lxr.php.net/) and Bonsai (http://bonsai.php.net/)
to look at PHP CVS repository in various ways.
To receive daily updates to ChangeLog and NEWS, send an empty message to
Happy hacking,
PHP Team