New files.

Please read README.CVS-RULES!

1 files changed, 88 insertions, 0 deletions

diff --git a/README.CVS-RULES b/README.CVS-RULES
new file mode 100644
index 0000000000..8a09e4a385
--- /dev/null
+++ b/README.CVS-RULES
@@ -0,0 +1,88 @@
+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.
+
+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. 
+
+   3. Look at MAINTANERS 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.
+	
+
+The next few rules are more of a technical nature.
+
+   1. DO NOT TOUCH ChangeLog! It is automagically updated from the commit
+      messages every day. Woe be to those who attempt to mess with it.
+
+   2. All news updates intended for public viewing, such as new features,
+      bug fixes, improvements, etc., should go into the NEWS file. Also see
+      the note below about automatically updating NEWS in your commit message.
+
+   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.
+
+If a line begins with #, it is taken to be a comment and will not appear
+in the ChangeLog.  If the line begins with @, it will be redirected to the
+NEWS file. Everything else goes into the ChangeLog. 
+
+Example. Say you modified two files, datetime.c and string.c. In datetime.c
+you added a new format option for 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:
+
+(PHP date) Added new 'K' format modifier for printing out number of
+           days until New Year.
+@- Added new 'K' format modifier that will output the number of days
+   until Christmas. (Bob)
+
+For string.c:
+(php_trim) Fixed a memory leak resulting from improper use of zval_dtor().
+# Man, that thing was leaking all over the place!
+@- Memory leak in trim() function has finally been fixed. (Bob)
+
+The lines above marked with @ will go into NEWS file automagically, and the
+# line will be omitted from the ChangeLog. Alternatively, you might want
+to modify NEWS file directly and not use the @ lines.
+
+Happy hacking,
+
+PHP Team