summaryrefslogtreecommitdiff
path: root/README.cvs-commits
diff options
context:
space:
mode:
Diffstat (limited to 'README.cvs-commits')
-rw-r--r--README.cvs-commits52
1 files changed, 52 insertions, 0 deletions
diff --git a/README.cvs-commits b/README.cvs-commits
new file mode 100644
index 000000000..cc90ee981
--- /dev/null
+++ b/README.cvs-commits
@@ -0,0 +1,52 @@
+GTK+ is part of the GNOME CVS repository. At the current time, any
+person with write access to the GNOME repository, can make changes to
+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
+to ask people commiting to GTK+ to follow a few rules:
+
+0) Ask first. If your changes are major, or could possibly break existing
+ code, you should always ask. If your change is minor and you've
+ been working on GTK+ for a while it probably isn't necessary
+ to ask. But when in doubt, ask. Even if your change is correct,
+ 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
+ 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.
+
+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
+ will be reverted.
+
+3) There _must_ be a ChangeLog for every commit.
+
+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.
+
+Owen Taylor
+13 Aug 1998
+
+
+
+
+