-GTK+ is part of the GNOME Subversion repository. At the current time, any
+GTK+ is part of the GNOME git 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:
+about GTK+ that has been built up over the years, we'd like to ask
+people committing 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
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:
+ to gtk-devel-list@gnome.org. (Subscription address:
gtk-devel-list-request@gnome.org.) This is a good place to ask
- about intended changes.
+ about intended changes.
#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,
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 without ChangeLog entries
- will be reverted.
-
-3) There _must_ be a ChangeLog for every commit.
+2) With git, we no longer maintain a ChangeLog file, but you are expected
+ to produce a meaningful commit message. Changes without a sufficient
+ commit message will be reverted. See below for the expected format
+ of commit messages.
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.
+* When developing larger features or complicated bug fixes, it is
+ advisable to work in a branch in your own cloned GTK+ repository.
+ You may even consider making your repository publically available
+ so that others can easily test and review your changes.
+
+* The expected format for git commit messages is as follows:
+
+=== begin example commit ===
+Short explanation of the commit
+
+Longer explanation explaining exactly what's changed, whether any
+external or private interfaces changed, what bugs were fixed (with bug
+tracker reference if applicable) and so forth. Be concise but not too brief.
+=== end example commit ===
-* The ChangeLog entries should preferably match in date format
- with the existing entries. You can set how emacs does this
- by using customize mode:
+ - Always add a brief description of the commit to the _first_ line of
+ the commit and terminate by two newlines (it will work without the
+ second newline, but that is not nice for the interfaces).
- - M-x customize
- - set Programming/Tools/ChangeLog/Add Log Time Format to
- 'Old Format'
+ - First line (the brief description) must only be one sentence and
+ should start with a capital letter unless it starts with a lowercase
+ symbol or identifier. Don't use a trailing period either. Don't exceed
+ 72 characters.
+
+ - The main description (the body) is normal prose and should use normal
+ punctuation and capital letters where appropriate. Normally, for patches
+ sent to a mailing list it's copied from there.
+
+ - When committing code on behalf of others use the --author option, e.g.
+ git commit -a --author "Joe Coder <joe@coder.org>" and --signoff.
- Or, set the add-log-time-format to 'current-time-string in
- your .emacs file.
Owen Taylor
13 Aug 1998
17 Apr 2001
+
+Matthias Clasen
+31 Mar 2009
projects / ~andy / gtk / blobdiff