mirror of
https://gitlab.gnome.org/GNOME/gtk.git
synced 2024-09-20 05:50:11 +00:00
eced717280
Tue Apr 17 13:47:12 2001 Owen Taylor <otaylor@redhat.com> * configure.in: Don't put -lgthread in GLIB_LIBS, GLIB_DEPLIBS * gtk/gtktypeutils.h gtk/gtksignals.h: Restore proper parameter names to compatibility #defines so docs work. * gtk/gtkenums.h: Remove GtkMenuFactoryType * gtk/gtkwindow.c gtk/gtkdnd.c: Docs cleanups. * configure.in: Don't include -lgthread in GLIB_LIBS, GLIB_DEPLIBS * tests/testgtkrc: No magenta cursors, please. * README.in INSTALL.in HACKING README.cvs-commits: Updated. * gtk/gtkenums.h (enum): Remove left over GtkMenuFactoryType.
55 lines
2.2 KiB
Plaintext
55 lines
2.2 KiB
Plaintext
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 4 years, 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@gnome.org. (Subscription address:
|
|
gtk-devel-list-request@gnome.org.) This is a good place to ask
|
|
about intended changes.
|
|
|
|
#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
|
|
17 Apr 2001
|