Return to README.SVN-RULES CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / php

Annotation of embedaddon/php/README.SVN-RULES, revision 1.1.1.1

1.1       misho       1: ====================
                      2:   SVN Commit Rules
                      3: ====================
                      4: 
                      5: This is the first file you should be reading after you get your SVN account.
                      6: We'll assume you're basically familiar with SVN, but feel free to post
                      7: your questions on the mailing list. Please have a look at
                      8: http://svnbook.red-bean.com/ for more detailed information on SVN.
                      9: 
                     10: PHP is developed through the efforts of a large number of people.
                     11: Collaboration is a Good Thing(tm), and SVN lets us do this. Thus, following
                     12: some basic rules with regards to SVN usage will::
                     13: 
                     14:    a. Make everybody happier, especially those responsible for maintaining
                     15:       the SVN itself.
                     16: 
                     17:    b. Keep the changes consistently well documented and easily trackable.
                     18: 
                     19:    c. Prevent some of those 'Oops' moments.
                     20: 
                     21:    d. Increase the general level of good will on planet Earth.
                     22: 
                     23: Having said that, here are the organizational rules::
                     24: 
                     25:    1. Respect other people working on the project.
                     26: 
                     27:    2. Discuss any significant changes on the list before committing and get
                     28:       confirmation from the release manager for the given branch.
                     29: 
                     30:    3. Look at EXTENSIONS file to see who is the primary maintainer of
                     31:       the code you want to contribute to.
                     32: 
                     33:    4. If you "strongly disagree" about something another person did, don't
                     34:       start fighting publicly - take it up in private email.
                     35: 
                     36:    5. If you don't know how to do something, ask first!
                     37: 
                     38:    6. Test your changes before committing them. We mean it. Really.
                     39:       To do so use "make test".
                     40: 
                     41:    7. For development use the --enable-maintainer-zts switch to ensure your
                     42:       code handles TSRM correctly and doesn't break for those who need that.
                     43: 
                     44: Currently we have the following branches in use::
                     45: 
                     46:   trunk             Will become PHP 6.0. This CVS branch is for active development.
                     47: 
                     48:   branches/PHP_5_3  Is used to release the PHP 5.3.x series. It still allows for
                     49:                     larger enhancements.
                     50: 
                     51:   branches/PHP_5_2  Is used to release the PHP 5.2.x series. Only bugfixes are permitted
                     52:                     on this branch (Consult the releasemaster prior to commit).
                     53: 
                     54:   branches/PHP_5_1  This branch is closed.
                     55: 
                     56:   branches/PHP_4_4  This branch is closed.
                     57: 
                     58: The next few rules are more of a technical nature::
                     59: 
                     60:    1. All changes should first go to trunk and then get merged from trunk
                     61:       (aka MFH'ed) to all other relevant branches.
                     62: 
                     63:    2. DO NOT TOUCH ChangeLog! It is automagically updated from the commit
                     64:       messages every day. Woe be to those who attempt to mess with it.
                     65: 
                     66:    3. All news updates intended for public viewing, such as new features,
                     67:       bug fixes, improvements, etc., should go into the NEWS file of the
                     68:       *first* to be released version with the given change. In other words
                     69:       any NEWS file change only needs to done in one branch.
                     70: 
                     71:       NB! Lines, starting with @ will go automagically into NEWS file, but
                     72:       this is NOT recommended, though. Please, add news entries directly to
                     73:       NEWS file and don't forget to keep them adjusted and sorted.
                     74: 
                     75:    4. Do not commit multiple file and dump all messages in one commit. If you
                     76:       modified several unrelated files, commit each group separately and
                     77:       provide a nice commit message for each one. See example below.
                     78: 
                     79:    5. Do write your commit message in such a way that it makes sense even
                     80:       without the corresponding diff. One should be able to look at it, and
                     81:       immediately know what was modified. Definitely include the function name
                     82:       in the message as shown below.
                     83: 
                     84:    6. In your commit messages, keep each line shorter than 80 characters. And
                     85:       try to align your lines vertically, if they wrap. It looks bad otherwise.
                     86: 
                     87:    7. If you modified a function that is callable from PHP, prepend PHP to
                     88:       the function name as shown below.
                     89: 
                     90: 
                     91: The format of the commit messages is pretty simple.
                     92: 
                     93: Use a - to start a new item in your commit message.
                     94: 
                     95: If a line begins with #, it is taken to be a comment and will not appear
                     96: in the ChangeLog. Everything else goes into the ChangeLog.
                     97: 
                     98: It is important to note that if your comment or news logline spans multiple
                     99: lines, you have to put # at the beginning of **every** such line.
                    100: 
                    101: Example. Say you modified two files, datetime.c and string.c. In datetime.c you
                    102: added a new format option for the date() function, and in string.c you fixed a
                    103: memory leak in php_trim(). Don't commit both of these at once. Commit them
                    104: separately and try to make sure your commit messages look something like the
                    105: following.
                    106: 
                    107: For datetime.c::
                    108: 
                    109:   - Added new 'K' format modifier to date() for printing out number of days
                    110:     until New Year's Eve.
                    111: 
                    112: For string.c::
                    113: 
                    114:   - Fixed a memory leak in php_trim() resulting from improper use of zval_dtor().
                    115:   #- Man, that thing was leaking all over the place!
                    116: 
                    117: The # lines will be omitted from the ChangeLog automagically.
                    118: 
                    119: Use the [DOC] tag in your log message whenever you feel that your changes
                    120: imply a documentation modification. The php-doc team will automatically
                    121: get notified about your commit through the php-doc mailing list.
                    122: 
                    123: If you fix some bugs, you should note the bug ID numbers in your
                    124: commit message. Bug ID should be prefixed by "#" for easier access to
                    125: bug report when developers are browsing CVS via LXR or Bonsai.
                    126: 
                    127: Example::
                    128: 
                    129:   Fixed bug #14016 (pgsql notice handler double free crash bug.)
                    130: 
                    131: If you don't see your messages in ChangeLog right away, don't worry!
                    132: These files are updated once a day, so your stuff will not show up until
                    133: somewhat later.
                    134: 
                    135: When you change the NEWS file for a bug fix, then please keep the bugs
                    136: sorted in decreasing order under the fixed version.
                    137: 
                    138: You can use LXR (http://lxr.php.net/) and Bonsai (http://bonsai.php.net/)
                    139: to look at PHP SVN repository in various ways.
                    140: 
                    141: To receive daily updates to ChangeLog and NEWS, send an empty message to
                    142: php-cvs-daily-subscribe@lists.php.net.
                    143: 
                    144: Happy hacking,
                    145: 
                    146: PHP Team