mirror of
https://github.com/php/php-src.git
synced 2025-01-18 09:43:36 +08:00
Move and update README.SVN-RULES to README.GIT-RULES
This commit is contained in:
Johannes Schlüter
parent
8c4294bcb4
commit
e0d5138660
124
README.GIT-RULES
Normal file
124
README.GIT-RULES
Normal file
@ -0,0 +1,124 @@
|
||||
====================
|
||||
Git Commit Rules
|
||||
====================
|
||||
|
||||
This is the first file you should be reading when contributing code via Git.
|
||||
We'll assume you're basically familiar with Git, but feel free to post
|
||||
your questions on the mailing list. Please have a look at
|
||||
http://git-scm.com/ for more detailed information on Git.
|
||||
|
||||
PHP is developed through the efforts of a large number of people.
|
||||
Collaboration is a Good Thing(tm), and Git lets us do this. Thus, following
|
||||
some basic rules with regards to Git usage will::
|
||||
|
||||
a. Make everybody happier, especially those responsible for maintaining
|
||||
Git 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 and get
|
||||
confirmation from the release manager for the given branch.
|
||||
|
||||
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.
|
||||
To do so use "make test".
|
||||
|
||||
7. For development use the --enable-maintainer-zts switch to ensure your
|
||||
code handles TSRM correctly and doesn't break for those who need that.
|
||||
|
||||
Currently we have the following branches in use::
|
||||
|
||||
master The active development branch.
|
||||
|
||||
PHP-5.4 Is used to release the PHP 5.4.x series. It still allows for
|
||||
larger enhancements.
|
||||
|
||||
PHP-5.3 Is used to release the PHP 5.3.x series. This is current
|
||||
stable version and is open for bugfixes only.
|
||||
|
||||
PHP-5.2 Is used to release the PHP 5.2.x series. It is closed for
|
||||
changes now.
|
||||
|
||||
PHP-5.1 This branch is closed.
|
||||
|
||||
PHP-4.4 This branch is closed.
|
||||
|
||||
The next few rules are more of a technical nature::
|
||||
|
||||
1. All changes should first go to the lowest branch (i.e. 5.3) and then
|
||||
get merged up to all other branches. If a change is not needed for
|
||||
later branches (i.e. fixes for features which where dropped from later
|
||||
branches) an empty merge should be done.
|
||||
|
||||
2. All news updates intended for public viewing, such as new features,
|
||||
bug fixes, improvements, etc., should go into the NEWS file of the
|
||||
*first* to be released version with the given change. In other words
|
||||
any NEWS file change only needs to done in one branch.
|
||||
|
||||
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.
|
||||
|
||||
<max 79 characters short description>\n
|
||||
\n
|
||||
<long description, 79 chars per line>
|
||||
\n
|
||||
|
||||
An Example from the git project (commit 2b34e486bc):
|
||||
|
||||
pack-objects: Fix compilation with NO_PTHREDS
|
||||
|
||||
It looks like commit 99fb6e04 (pack-objects: convert to use
|
||||
parse_options(), 2012-02-01) moved the #ifdef NO_PTHREDS around but
|
||||
hasn't noticed that the 'arg' variable no longer is available.
|
||||
|
||||
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 bug #14016 (pgsql notice handler double free crash bug.)
|
||||
|
||||
When you change the NEWS file for a bug fix, then please keep the bugs
|
||||
sorted in decreasing order under the fixed version.
|
||||
|
||||
You can use OpenGrok (http://lxr.php.net/) and gitweb (http://git.php.net/)
|
||||
to look at PHP Git repository in various ways.
|
||||
|
||||
|
||||
For further information on the process and further details please refer to
|
||||
https://wiki.php.net/vcs/gitworkflow and https://wiki.php.net/vcs/gitfaq
|
||||
|
||||
Happy hacking,
|
||||
|
||||
PHP Team
|
||||
146
README.SVN-RULES
146
README.SVN-RULES
@ -1,146 +0,0 @@
|
||||
====================
|
||||
SVN Commit Rules
|
||||
====================
|
||||
|
||||
This is the first file you should be reading after you get your SVN account.
|
||||
We'll assume you're basically familiar with SVN, but feel free to post
|
||||
your questions on the mailing list. Please have a look at
|
||||
http://svnbook.red-bean.com/ for more detailed information on SVN.
|
||||
|
||||
PHP is developed through the efforts of a large number of people.
|
||||
Collaboration is a Good Thing(tm), and SVN lets us do this. Thus, following
|
||||
some basic rules with regards to SVN usage will::
|
||||
|
||||
a. Make everybody happier, especially those responsible for maintaining
|
||||
the SVN 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 and get
|
||||
confirmation from the release manager for the given branch.
|
||||
|
||||
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.
|
||||
To do so use "make test".
|
||||
|
||||
7. For development use the --enable-maintainer-zts switch to ensure your
|
||||
code handles TSRM correctly and doesn't break for those who need that.
|
||||
|
||||
Currently we have the following branches in use::
|
||||
|
||||
trunk Will become PHP 6.0. This CVS branch is for active development.
|
||||
|
||||
branches/PHP_5_3 Is used to release the PHP 5.3.x series. It still allows for
|
||||
larger enhancements.
|
||||
|
||||
branches/PHP_5_2 Is used to release the PHP 5.2.x series. Only bugfixes are permitted
|
||||
on this branch (Consult the releasemaster prior to commit).
|
||||
|
||||
branches/PHP_5_1 This branch is closed.
|
||||
|
||||
branches/PHP_4_4 This branch is closed.
|
||||
|
||||
The next few rules are more of a technical nature::
|
||||
|
||||
1. All changes should first go to trunk and then get merged from trunk
|
||||
(aka MFH'ed) to all other relevant branches.
|
||||
|
||||
2. DO NOT TOUCH ChangeLog! It is automagically updated from the commit
|
||||
messages every day. Woe be to those who attempt to mess with it.
|
||||
|
||||
3. All news updates intended for public viewing, such as new features,
|
||||
bug fixes, improvements, etc., should go into the NEWS file of the
|
||||
*first* to be released version with the given change. In other words
|
||||
any NEWS file change only needs to done in one branch.
|
||||
|
||||
NB! Lines, starting with @ will go automagically into NEWS file, but
|
||||
this is NOT recommended, though. Please, add news entries directly to
|
||||
NEWS file and don't forget to keep them adjusted and sorted.
|
||||
|
||||
4. 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.
|
||||
|
||||
5. 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.
|
||||
|
||||
6. 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.
|
||||
|
||||
7. 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.
|
||||
|
||||
Use a - to start a new item in your commit message.
|
||||
|
||||
If a line begins with #, it is taken to be a comment and will not appear
|
||||
in the ChangeLog. 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 # at the beginning of **every** such line.
|
||||
|
||||
Example. Say you modified two files, datetime.c and string.c. In datetime.c you
|
||||
added a new format option for the 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::
|
||||
|
||||
- Added new 'K' format modifier to date() for printing out number of days
|
||||
until New Year's Eve.
|
||||
|
||||
For string.c::
|
||||
|
||||
- Fixed a memory leak in php_trim() resulting from improper use of zval_dtor().
|
||||
#- Man, that thing was leaking all over the place!
|
||||
|
||||
The # lines will be omitted from the ChangeLog automagically.
|
||||
|
||||
Use the [DOC] tag in your log message whenever you feel that your changes
|
||||
imply a documentation modification. The php-doc team will automatically
|
||||
get notified about your commit through the php-doc mailing list.
|
||||
|
||||
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 bug #14016 (pgsql notice handler double free crash bug.)
|
||||
|
||||
If you don't see your messages in ChangeLog right away, don't worry!
|
||||
These files are updated once a day, so your stuff will not show up until
|
||||
somewhat later.
|
||||
|
||||
When you change the NEWS file for a bug fix, then please keep the bugs
|
||||
sorted in decreasing order under the fixed version.
|
||||
|
||||
You can use LXR (http://lxr.php.net/) and Bonsai (http://bonsai.php.net/)
|
||||
to look at PHP SVN repository in various ways.
|
||||
|
||||
To receive daily updates to ChangeLog and NEWS, send an empty message to
|
||||
php-cvs-daily-subscribe@lists.php.net.
|
||||
|
||||
Happy hacking,
|
||||
|
||||
PHP Team
|
||||
Loading…
Reference in New Issue
Block a user