| 1 | GTK+ is part of the GNOME CVS repository. At the current time, any |
|---|
| 2 | person with write access to the GNOME repository, can make changes to |
|---|
| 3 | GTK+. This is a good thing, in that it encourages many people to work |
|---|
| 4 | on GTK+, and progress can be made quickly. However, GTK+ is a fairly |
|---|
| 5 | large and complicated package that many other things depend on, so to |
|---|
| 6 | avoid unnecessary breakage, and to take advantage of the knowledge |
|---|
| 7 | about GTK+ that has been built up over the last 18 months, we'd like |
|---|
| 8 | to ask people commiting to GTK+ to follow a few rules: |
|---|
| 9 | |
|---|
| 10 | 0) Ask first. If your changes are major, or could possibly break existing |
|---|
| 11 | code, you should always ask. If your change is minor and you've |
|---|
| 12 | been working on GTK+ for a while it probably isn't necessary |
|---|
| 13 | to ask. But when in doubt, ask. Even if your change is correct, |
|---|
| 14 | somebody may know a better way to do things. |
|---|
| 15 | |
|---|
| 16 | If you are making changes to GTK+, you should be subscribed |
|---|
| 17 | to gtk-devel-list@redhat.com. (Subscription address: |
|---|
| 18 | gtk-devel-list-request@redhat.com.) This is a good place to ask |
|---|
| 19 | about intended changes. |
|---|
| 20 | |
|---|
| 21 | If you just want to make a trivial change, and don't want to subscribe, |
|---|
| 22 | you can also mail gtk-bugs@gtk.org. Or, alternatively, you can look in |
|---|
| 23 | the ChangeLog for somebody who has been making changes to the file |
|---|
| 24 | you want to change and email them. |
|---|
| 25 | |
|---|
| 26 | #gimp on byxnet (irc.gimp.org, irc2.gimp.org, irc3.gimp.org, |
|---|
| 27 | irc.germany.gimp.org...)s also a good place to find GTK+ developers to |
|---|
| 28 | discuss changes with, however, email to gtk-devel-list is the most |
|---|
| 29 | certain and preferred method. |
|---|
| 30 | |
|---|
| 31 | 1) Ask _first_. |
|---|
| 32 | |
|---|
| 33 | 2) There must be a ChangeLog for every commit. (If you discover that |
|---|
| 34 | you only committed half the files you meant to and need to fix that |
|---|
| 35 | up, or something, you don't need a new ChangeLog entry. But in general, |
|---|
| 36 | ChangeLog entries are mandatory.) Changes with out ChangeLog entries |
|---|
| 37 | will be reverted. |
|---|
| 38 | |
|---|
| 39 | 3) There _must_ be a ChangeLog for every commit. |
|---|
| 40 | |
|---|
| 41 | Notes: |
|---|
| 42 | |
|---|
| 43 | * If you are going to be changing many files in an experimental fashion, |
|---|
| 44 | it probably is a good idea to create a separate branch for your changes. |
|---|
| 45 | |
|---|
| 46 | * The ChangeLog entries should preferrably match in date format |
|---|
| 47 | with the existing entries. You can set how emacs does this |
|---|
| 48 | by using customize mode: |
|---|
| 49 | |
|---|
| 50 | - M-x customize |
|---|
| 51 | - set Programming/Tools/ChangeLog/Add Log Time Format to |
|---|
| 52 | 'Old Format' |
|---|
| 53 | |
|---|
| 54 | Or, set the add-log-time-format to 'current-time-string in |
|---|
| 55 | your .emacs file. |
|---|
| 56 | |
|---|
| 57 | Owen Taylor |
|---|
| 58 | 13 Aug 1998 |
|---|
| 59 | |
|---|
| 60 | |
|---|
| 61 | |
|---|
| 62 | |
|---|
| 63 | |
|---|
