Return to README.SVN-RULES CVS log

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

php 5.4.3+patches

    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             The active development branch. 
   47: 
   48:   branches/PHP_5_4  Is used to release the PHP 5.4.x series. In release
   49:                     process, only bugfixes and very small changes approved
   50:                     by RMs are allowed.
   51: 
   52:   branches/PHP_5_3  Is used to release the PHP 5.3.x series. This is current 
   53:                     stable version and is open for bugfixes and small
   54:                     improvements (check with RMs if in doubt).
   55: 
   56:   branches/PHP_5_2  Is used to release the PHP 5.2.x series. It is closed for 
   57:                     changes now.
   58: 
   59:   branches/PHP_5_1  This branch is closed.
   60: 
   61:   branches/PHP_4_4  This branch is closed.
   62: 
   63: The next few rules are more of a technical nature::
   64: 
   65:    1. All changes should first go to trunk and then get merged from trunk
   66:       (aka MFH'ed) to all other relevant branches.
   67: 
   68:    2. DO NOT TOUCH ChangeLog! It is automagically updated from the commit
   69:       messages every day. Woe be to those who attempt to mess with it.
   70: 
   71:    3. All news updates intended for public viewing, such as new features,
   72:       bug fixes, improvements, etc., should go into the NEWS file of the
   73:       *first* to be released version with the given change. In other words
   74:       any NEWS file change only needs to done in one branch.
   75: 
   76:       NB! Lines, starting with @ will go automagically into NEWS file, but
   77:       this is NOT recommended, though. Please, add news entries directly to
   78:       NEWS file and don't forget to keep them adjusted and sorted.
   79: 
   80:    4. Do not commit multiple file and dump all messages in one commit. If you
   81:       modified several unrelated files, commit each group separately and
   82:       provide a nice commit message for each one. See example below.
   83: 
   84:    5. Do write your commit message in such a way that it makes sense even
   85:       without the corresponding diff. One should be able to look at it, and
   86:       immediately know what was modified. Definitely include the function name
   87:       in the message as shown below.
   88: 
   89:    6. In your commit messages, keep each line shorter than 80 characters. And
   90:       try to align your lines vertically, if they wrap. It looks bad otherwise.
   91: 
   92:    7. If you modified a function that is callable from PHP, prepend PHP to
   93:       the function name as shown below.
   94: 
   95: 
   96: The format of the commit messages is pretty simple.
   97: 
   98: Use a - to start a new item in your commit message.
   99: 
  100: If a line begins with #, it is taken to be a comment and will not appear
  101: in the ChangeLog. Everything else goes into the ChangeLog.
  102: 
  103: It is important to note that if your comment or news logline spans multiple
  104: lines, you have to put # at the beginning of **every** such line.
  105: 
  106: Example. Say you modified two files, datetime.c and string.c. In datetime.c you
  107: added a new format option for the date() function, and in string.c you fixed a
  108: memory leak in php_trim(). Don't commit both of these at once. Commit them
  109: separately and try to make sure your commit messages look something like the
  110: following.
  111: 
  112: For datetime.c::
  113: 
  114:   - Added new 'K' format modifier to date() for printing out number of days
  115:     until New Year's Eve.
  116: 
  117: For string.c::
  118: 
  119:   - Fixed a memory leak in php_trim() resulting from improper use of zval_dtor().
  120:   #- Man, that thing was leaking all over the place!
  121: 
  122: The # lines will be omitted from the ChangeLog automagically.
  123: 
  124: Use the [DOC] tag in your log message whenever you feel that your changes
  125: imply a documentation modification. The php-doc team will automatically
  126: get notified about your commit through the php-doc mailing list.
  127: 
  128: If you fix some bugs, you should note the bug ID numbers in your
  129: commit message. Bug ID should be prefixed by "#" for easier access to
  130: bug report when developers are browsing CVS via LXR or Bonsai.
  131: 
  132: Example::
  133: 
  134:   Fixed bug #14016 (pgsql notice handler double free crash bug.)
  135: 
  136: If you don't see your messages in ChangeLog right away, don't worry!
  137: These files are updated once a day, so your stuff will not show up until
  138: somewhat later.
  139: 
  140: When you change the NEWS file for a bug fix, then please keep the bugs
  141: sorted in decreasing order under the fixed version.
  142: 
  143: You can use LXR (http://lxr.php.net/) and Bonsai (http://bonsai.php.net/)
  144: to look at PHP SVN repository in various ways.
  145: 
  146: To receive daily updates to ChangeLog and NEWS, send an empty message to
  147: php-cvs-daily-subscribe@lists.php.net.
  148: 
  149: Happy hacking,
  150: 
  151: PHP Team