AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity

Added file README.cvs-commits

Browse Source 
* Added file README.cvs-commits
This commit is contained in:
Owen Taylor 1998-08-13 21:18:43 +00:00
parent 814bfe1305
commit 0dece0ba4f
1 changed files with 52 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
README.cvs-commits Normal file
View File

@ -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