summaryrefslogtreecommitdiff
path: root/README.GIT-RULES
diff options
context:
space:
mode:
authorLorry Tar Creator <lorry-tar-importer@baserock.org>2013-03-14 05:42:27 +0000
committer <>2013-04-03 16:25:08 +0000
commitc4dd7a1a684490673e25aaf4fabec5df138854c4 (patch)
tree4d57c44caae4480efff02b90b9be86f44bf25409 /README.GIT-RULES
downloadphp2-c4dd7a1a684490673e25aaf4fabec5df138854c4.tar.gz
Imported from /home/lorry/working-area/delta_php2/php-5.4.13.tar.bz2.HEADphp-5.4.13master
Diffstat (limited to 'README.GIT-RULES')
-rw-r--r--README.GIT-RULES124
1 files changed, 124 insertions, 0 deletions
diff --git a/README.GIT-RULES b/README.GIT-RULES
new file mode 100644
index 0000000..289a4e7
--- /dev/null
+++ b/README.GIT-RULES
@@ -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