Annotation of embedaddon/php/README.GIT-RULES, revision 1.1.1.3
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,
1.1.1.3 ! misho 72: bug fixes, improvements, etc., should go into the NEWS file of *any
! 73: stable release* version with the given change. In other words,
! 74: news about a bug fix which went into PHP-5.4, PHP-5.5 and master
! 75: should be noted in both PHP-5.4/NEWS and PHP-5.5/NEWS but
! 76: not master, which is not a public released version yet.
1.1 misho 77:
78: 3. Do not commit multiple file and dump all messages in one commit. If you
79: modified several unrelated files, commit each group separately and
80: provide a nice commit message for each one. See example below.
81:
82: 4. Do write your commit message in such a way that it makes sense even
83: without the corresponding diff. One should be able to look at it, and
84: immediately know what was modified. Definitely include the function name
85: in the message as shown below.
86:
87: 5. In your commit messages, keep each line shorter than 80 characters. And
88: try to align your lines vertically, if they wrap. It looks bad otherwise.
89:
90: 6. If you modified a function that is callable from PHP, prepend PHP to
91: the function name as shown below.
92:
93:
94: The format of the commit messages is pretty simple.
95:
96: <max 79 characters short description>\n
97: \n
98: <long description, 79 chars per line>
99: \n
100:
101: An Example from the git project (commit 2b34e486bc):
102:
103: pack-objects: Fix compilation with NO_PTHREDS
104:
105: It looks like commit 99fb6e04 (pack-objects: convert to use
106: parse_options(), 2012-02-01) moved the #ifdef NO_PTHREDS around but
107: hasn't noticed that the 'arg' variable no longer is available.
108:
109: If you fix some bugs, you should note the bug ID numbers in your
110: commit message. Bug ID should be prefixed by "#" for easier access to
111: bug report when developers are browsing CVS via LXR or Bonsai.
112:
113: Example::
114:
115: Fixed bug #14016 (pgsql notice handler double free crash bug.)
116:
117: When you change the NEWS file for a bug fix, then please keep the bugs
118: sorted in decreasing order under the fixed version.
119:
120: You can use OpenGrok (http://lxr.php.net/) and gitweb (http://git.php.net/)
121: to look at PHP Git repository in various ways.
122:
123:
124: For further information on the process and further details please refer to
125: https://wiki.php.net/vcs/gitworkflow and https://wiki.php.net/vcs/gitfaq
126:
127: Happy hacking,
128:
129: PHP Team
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to README.GIT-RULES CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / php