Mirrors
/
php
mirror of https://github.com/php/php-src
3
0
Fork 0
Code Releases Activity
Browse Source

Move and update README.SVN-RULES to README.GIT-RULES

pull/56/head
Johannes Schlüter 14 years ago
parent
8c4294bcb4
commit
e0d5138660
2 changed files with 124 additions and 146 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 124
      README.GIT-RULES
  2. 146
      README.SVN-RULES

124
README.GIT-RULES
View 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
View File

@ -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
Write Preview
Loading…
Cancel
Save