README.commits 2.15 KB
Newer Older
1
GTK+ is part of the GNOME Subversion repository. At the current time, any
2 3 4 5 6
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
7
about GTK+ that has been built up over the last 4 years, we'd like
8 9 10 11 12 13 14 15 16
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
17 18
   to gtk-devel-list@gnome.org. (Subscription address:  
   gtk-devel-list-request@gnome.org.) This is a good place to ask
19 20
   about intended changes. 

Manish Singh's avatar
Manish Singh committed
21 22 23 24
   #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.
25 26 27 28 29 30

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,
31
   ChangeLog entries are mandatory.) Changes without ChangeLog entries
32 33 34 35 36 37 38 39 40
   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.

41
* The ChangeLog entries should preferably match in date format
42 43 44 45 46 47 48 49 50 51
  with the existing entries. You can set how emacs does this
  by using customize mode:

  - M-x customize
  - set Programming/Tools/ChangeLog/Add Log Time Format to
    'Old Format'

 Or, set the add-log-time-format to 'current-time-string in
 your .emacs file.

52 53
Owen Taylor
13 Aug 1998
54
17 Apr 2001