File: README.cvs-commits

package info (click to toggle)
gtk%2B1.2 1.2.10-17
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 14,464 kB
  • ctags: 12,960
  • sloc: ansic: 137,190; sh: 13,274; makefile: 1,159; perl: 328; awk: 274; lisp: 7
file content (63 lines) | stat: -rw-r--r-- 2,470 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
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.

* The ChangeLog entries should preferrably match in date format
  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.

Owen Taylor
13 Aug 1998