- Remove unused code/options from the code. Warn about their usage while

[~andy/gtk] / README.cvs-commits

diff --git a/README.cvs-commits b/README.cvs-commits
index 12231d72b6c5eb46452733dd0fc14a3f5a01656e..38b047a9bea8f3277615507562333c14b7296f0c 100644 (file)
--- a/README.cvs-commits
+++ b/README.cvs-commits
@@ -4,7 +4,7 @@ GTK+. This is a good thing, in that it encourages many people to work
 on GTK+, and progress can be made quickly. However, GTK+ is a fairly
 large and complicated package that many other things depend on, so to
 avoid unnecessary breakage, and to take advantage of the knowledge
-about GTK+ that has been built up over the last 18 months, we'd like
+about GTK+ that has been built up over the last 4 years, we'd like
 to ask people commiting to GTK+ to follow a few rules:
 
 0) Ask first. If your changes are major, or could possibly break existing
@@ -14,26 +14,21 @@ to ask people commiting to GTK+ to follow a few rules:
    somebody may know a better way to do things.
 
    If you are making changes to GTK+, you should be subscribed
-   to gtk-devel-list@redhat.com. (Subscription address:  
-   gtk-devel-list-request@redhat.com.) This is a good place to ask
+   to gtk-devel-list@gnome.org. (Subscription address:  
+   gtk-devel-list-request@gnome.org.) This is a good place to ask
    about intended changes. 
 
-   If you just want to make a trivial change, and don't want to subscribe, 
-   you can also mail gtk-bugs@gtk.org. Or, alternatively, you can look in 
-   the ChangeLog for somebody who has been making changes to the file 
-   you want to change and email them.
-
-   #gimp on byxnet (irc.gimp.org, irc2.gimp.org, irc3.gimp.org, 
-   irc.germany.gimp.org...)s also a good place to find GTK+ developers to
-   discuss changes with, however, email to gtk-devel-list is the most
-   certain and preferred method.
+   #gtk+ on GIMPNet (irc.gimp.org, irc.us.gimp.org, irc.eu.gimp.org, ...)
+   is also a good place to find GTK+ developers to discuss changes with,
+   however, email to gtk-devel-list is the most certain and preferred
+   method.
 
 1) Ask _first_.
 
 2) There must be a ChangeLog for every commit. (If you discover that
    you only committed half the files you meant to and need to fix that
    up, or something, you don't need a new ChangeLog entry. But in general,
-   ChangeLog entries are mandatory.) Changes with out ChangeLog entries
+   ChangeLog entries are mandatory.) Changes without ChangeLog entries
    will be reverted.
 
 3) There _must_ be a ChangeLog for every commit.
@@ -43,7 +38,7 @@ Notes:
 * If you are going to be changing many files in an experimental fashion,
   it probably is a good idea to create a separate branch for your changes.
 
-* The ChangeLog entries should preferrably match in date format
+* The ChangeLog entries should preferably match in date format
   with the existing entries. You can set how emacs does this
   by using customize mode:
 
@@ -56,8 +51,4 @@ Notes:
 
 Owen Taylor
 13 Aug 1998
-
-
-
-
-
+17 Apr 2001