Annotation of embedaddon/php/README.GIT-RULES, revision 1.1.1.2

1.1       misho       1: ====================
                      2:   Git Commit Rules
                      3: ====================
                      4: 
                      5: This is the first file you should be reading when contributing code via Git.
                      6: We'll assume you're basically familiar with Git, but feel free to post
                      7: your questions on the mailing list. Please have a look at
                      8: http://git-scm.com/ for more detailed information on Git.
                      9: 
                     10: PHP is developed through the efforts of a large number of people.
                     11: Collaboration is a Good Thing(tm), and Git lets us do this. Thus, following
                     12: some basic rules with regards to Git usage will::
                     13: 
                     14:    a. Make everybody happier, especially those responsible for maintaining
                     15:       Git 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:   master    The active development branch. 
                     47: 
1.1.1.2 ! misho      48:   PHP-5.5   Is used to release the PHP 5.5.x series. This is a current
        !            49:             stable version and is open for bugfixes only.
1.1       misho      50: 
1.1.1.2 ! misho      51:   PHP-5.4   Is used to release the PHP 5.4.x series. This is a current
1.1       misho      52:             stable version and is open for bugfixes only.
                     53: 
1.1.1.2 ! misho      54:   PHP-5.3   Is used to release the PHP 5.3.x series. This is currently 
        !            55:             in extended support and open forsecurity fixes only. Triaged
        !            56:             via security@php.net
        !            57: 
        !            58:   PHP-5.2   This branch is closed.
1.1       misho      59: 
                     60:   PHP-5.1   This branch is closed.
                     61: 
                     62:   PHP-4.4   This branch is closed.
                     63: 
                     64: The next few rules are more of a technical nature::
                     65: 
                     66:    1. All changes should first go to the lowest branch (i.e. 5.3) and then 
                     67:       get merged up to all other branches. If a change is not needed for
                     68:       later branches (i.e. fixes for features which where dropped from later
                     69:       branches) an empty merge should be done.
                     70: 
                     71:    2. 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:    3. Do not commit multiple file and dump all messages in one commit. If you
                     77:       modified several unrelated files, commit each group separately and
                     78:       provide a nice commit message for each one. See example below.
                     79: 
                     80:    4. Do write your commit message in such a way that it makes sense even
                     81:       without the corresponding diff. One should be able to look at it, and
                     82:       immediately know what was modified. Definitely include the function name
                     83:       in the message as shown below.
                     84: 
                     85:    5. In your commit messages, keep each line shorter than 80 characters. And
                     86:       try to align your lines vertically, if they wrap. It looks bad otherwise.
                     87: 
                     88:    6. If you modified a function that is callable from PHP, prepend PHP to
                     89:       the function name as shown below.
                     90: 
                     91: 
                     92: The format of the commit messages is pretty simple.
                     93: 
                     94: <max 79 characters short description>\n
                     95: \n
                     96: <long description, 79 chars per line>
                     97: \n
                     98: 
                     99: An Example from the git project (commit 2b34e486bc):
                    100: 
                    101: pack-objects: Fix compilation with NO_PTHREDS
                    102:   
                    103: It looks like commit 99fb6e04 (pack-objects: convert to use
                    104: parse_options(), 2012-02-01) moved the #ifdef NO_PTHREDS around but
                    105: hasn't noticed that the 'arg' variable no longer is available.
                    106: 
                    107: If you fix some bugs, you should note the bug ID numbers in your
                    108: commit message. Bug ID should be prefixed by "#" for easier access to
                    109: bug report when developers are browsing CVS via LXR or Bonsai.
                    110: 
                    111: Example::
                    112: 
                    113:   Fixed bug #14016 (pgsql notice handler double free crash bug.)
                    114: 
                    115: When you change the NEWS file for a bug fix, then please keep the bugs
                    116: sorted in decreasing order under the fixed version.
                    117: 
                    118: You can use OpenGrok (http://lxr.php.net/) and gitweb (http://git.php.net/)
                    119: to look at PHP Git repository in various ways.
                    120: 
                    121: 
                    122: For further information on the process and further details please refer to
                    123: https://wiki.php.net/vcs/gitworkflow and https://wiki.php.net/vcs/gitfaq
                    124: 
                    125: Happy hacking,
                    126: 
                    127: PHP Team

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>