dsp             Tue, 14 Jul 2009 09:55:55 +0000

URL: http://svn.php.net/viewvc?view=revision&revision=284065

Changed paths:
        D   php/php-src/branches/PHP_5_3/README.CVS-RULES
        A   php/php-src/branches/PHP_5_3/README.SVN-RULES

Log:
MFH: - cvs->svn
Deleted: php/php-src/branches/PHP_5_3/README.CVS-RULES
===================================================================
--- php/php-src/branches/PHP_5_3/README.CVS-RULES	2009-07-14 09:48:10 UTC (rev 284064)
+++ php/php-src/branches/PHP_5_3/README.CVS-RULES	2009-07-14 09:55:55 UTC (rev 284065)
@@ -1,146 +0,0 @@
-====================
-  CVS Commit Rules
-====================
-
-This is the first file you should be reading after you get your CVS account.
-We'll assume you're basically familiar with CVS, but feel free to post
-your questions on the mailing list. Please have a look at
-http://cvsbook.red-bean.com/ for more detailed information on CVS.
-
-PHP is developed through the efforts of a large number of people.
-Collaboration is a Good Thing(tm), and CVS lets us do this. Thus, following
-some basic rules with regards to CVS usage will::
-
-   a. Make everybody happier, especially those responsible for maintaining
-      the CVS 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 thos who need that.
-
-Currently we have the following branches in use::
-
-  HEAD     Will become PHP 6.0. This CVS branch is for active development.
-
-  PHP_5_3  Is used to release the PHP 5.3.x series. It still allows for
-           larger enhancements.
-
-  PHP_5_2  Is used to release the PHP 5.2.x series. Only bugfixes are permitted
-           on this branch (Consult the releasemaster prior to commit).
-
-  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 HEAD and then get merged from HEAD
-      (aka MFH'ed) to all other relevant branches.
-
-   2. DO NOT TOUCH ChangeLog! It is automagically updated from the commit
-      messages every day. Woe be to those who attempt to mess with it.
-
-   3. 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.
-
-      NB! Lines, starting with @ will go automagically into NEWS file, but
-      this is NOT recommended, though. Please, add news entries directly to
-      NEWS file and don't forget to keep them adjusted and sorted.
-
-   4. 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.
-
-   5. 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.
-
-   6. 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.
-
-   7. 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.
-
-Use a - to start a new item in your commit message.
-
-If a line begins with #, it is taken to be a comment and will not appear
-in the ChangeLog. Everything else goes into the ChangeLog.
-
-It is important to note that if your comment or news logline spans multiple
-lines, you have to put # at the beginning of **every** such line.
-
-Example. Say you modified two files, datetime.c and string.c. In datetime.c you
-added a new format option for the date() function, and in string.c you fixed a
-memory leak in php_trim(). Don't commit both of these at once. Commit them
-separately and try to make sure your commit messages look something like the
-following.
-
-For datetime.c::
-
-  - Added new 'K' format modifier to date() for printing out number of days
-    until New Year's Eve.
-
-For string.c::
-
-  - Fixed a memory leak in php_trim() resulting from improper use of zval_dtor().
-  #- Man, that thing was leaking all over the place!
-
-The # lines will be omitted from the ChangeLog automagically.
-
-Use the [DOC] tag in your log message whenever you feel that your changes
-imply a documentation modification. The php-doc team will automatically
-get notified about your commit through the php-doc mailing list.
-
-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.)
-
-If you don't see your messages in ChangeLog right away, don't worry!
-These files are updated once a day, so your stuff will not show up until
-somewhat later.
-
-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 LXR (http://lxr.php.net/) and Bonsai (http://bonsai.php.net/)
-to look at PHP CVS repository in various ways.
-
-To receive daily updates to ChangeLog and NEWS, send an empty message to
-php-cvs-daily-subscr...@lists.php.net.
-
-Happy hacking,
-
-PHP Team

Copied: php/php-src/branches/PHP_5_3/README.SVN-RULES (from rev 284034, php/php-src/branches/PHP_5_3/README.CVS-RULES)
===================================================================
--- php/php-src/branches/PHP_5_3/README.SVN-RULES	                        (rev 0)
+++ php/php-src/branches/PHP_5_3/README.SVN-RULES	2009-07-14 09:55:55 UTC (rev 284065)
@@ -0,0 +1,146 @@
+====================
+  SVN Commit Rules
+====================
+
+This is the first file you should be reading after you get your SVN account.
+We'll assume you're basically familiar with SVN, but feel free to post
+your questions on the mailing list. Please have a look at
+http://svnbook.red-bean.com/ for more detailed information on SVN.
+
+PHP is developed through the efforts of a large number of people.
+Collaboration is a Good Thing(tm), and SVN lets us do this. Thus, following
+some basic rules with regards to SVN usage will::
+
+   a. Make everybody happier, especially those responsible for maintaining
+      the SVN 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 thos who need that.
+
+Currently we have the following branches in use::
+
+  trunk             Will become PHP 6.0. This CVS branch is for active development.
+
+  branches/PHP_5_3  Is used to release the PHP 5.3.x series. It still allows for
+                    larger enhancements.
+
+  branches/PHP_5_2  Is used to release the PHP 5.2.x series. Only bugfixes are permitted
+                    on this branch (Consult the releasemaster prior to commit).
+
+  branches/PHP_5_1  This branch is closed.
+
+  branches/PHP_4_4  This branch is closed.
+
+The next few rules are more of a technical nature::
+
+   1. All changes should first go to trunk and then get merged from trunk
+      (aka MFH'ed) to all other relevant branches.
+
+   2. DO NOT TOUCH ChangeLog! It is automagically updated from the commit
+      messages every day. Woe be to those who attempt to mess with it.
+
+   3. 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.
+
+      NB! Lines, starting with @ will go automagically into NEWS file, but
+      this is NOT recommended, though. Please, add news entries directly to
+      NEWS file and don't forget to keep them adjusted and sorted.
+
+   4. 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.
+
+   5. 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.
+
+   6. 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.
+
+   7. 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.
+
+Use a - to start a new item in your commit message.
+
+If a line begins with #, it is taken to be a comment and will not appear
+in the ChangeLog. Everything else goes into the ChangeLog.
+
+It is important to note that if your comment or news logline spans multiple
+lines, you have to put # at the beginning of **every** such line.
+
+Example. Say you modified two files, datetime.c and string.c. In datetime.c you
+added a new format option for the date() function, and in string.c you fixed a
+memory leak in php_trim(). Don't commit both of these at once. Commit them
+separately and try to make sure your commit messages look something like the
+following.
+
+For datetime.c::
+
+  - Added new 'K' format modifier to date() for printing out number of days
+    until New Year's Eve.
+
+For string.c::
+
+  - Fixed a memory leak in php_trim() resulting from improper use of zval_dtor().
+  #- Man, that thing was leaking all over the place!
+
+The # lines will be omitted from the ChangeLog automagically.
+
+Use the [DOC] tag in your log message whenever you feel that your changes
+imply a documentation modification. The php-doc team will automatically
+get notified about your commit through the php-doc mailing list.
+
+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.)
+
+If you don't see your messages in ChangeLog right away, don't worry!
+These files are updated once a day, so your stuff will not show up until
+somewhat later.
+
+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 LXR (http://lxr.php.net/) and Bonsai (http://bonsai.php.net/)
+to look at PHP SVN repository in various ways.
+
+To receive daily updates to ChangeLog and NEWS, send an empty message to
+php-cvs-daily-subscr...@lists.php.net.
+
+Happy hacking,
+
+PHP Team
-- 
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to