1GLib is part of the GNOME git repository. At the current time, any 2person with write access to the GNOME repository, can make changes to 3GLib. This is a good thing, in that it encourages many people to work 4on GLib, and progress can be made quickly. However, GLib is a fairly 5large and complicated package that many other things depend on, so to 6avoid unnecessary breakage, and to take advantage of the knowledge 7about GLib that has been built up over the years, we'd like to ask 8people committing to GLib to follow a few rules: 9 100) 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 GLib 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 GLib, you should be subscribed 17 to gtk-devel-list@gnome.org. (Subscription address: 18 gtk-devel-list-request@gnome.org.) This is a good place to ask 19 about intended changes. 20 21 #gtk+ on GIMPNet (irc.gimp.org, irc.us.gimp.org, irc.eu.gimp.org, ...) 22 is also a good place to find GTK+ developers to discuss changes with, 23 however, email to gtk-devel-list is the most certain and preferred 24 method. 25 261) Ask _first_. 27 282) With git, we no longer maintain a ChangeLog file, but you are expected 29 to produce a meaningful commit message. Changes without a sufficient 30 commit message will be reverted. See below for the expected format 31 of commit messages. 32 33Notes: 34 35* When developing larger features or complicated bug fixes, it is 36 advisable to work in a branch in your own cloned GLib repository. 37 You may even consider making your repository publically available 38 so that others can easily test and review your changes. 39 40* The expected format for git commit messages is as follows: 41 42=== begin example commit === 43Short explanation of the commit 44 45Longer explanation explaining exactly what's changed, whether any 46external or private interfaces changed, what bugs were fixed (with bug 47tracker reference if applicable) and so forth. Be concise but not too brief. 48=== end example commit === 49 50 - Always add a brief description of the commit to the _first_ line of 51 the commit and terminate by two newlines (it will work without the 52 second newline, but that is not nice for the interfaces). 53 54 - First line (the brief description) must only be one sentence and 55 should start with a capital letter unless it starts with a lowercase 56 symbol or identifier. Don't use a trailing period either. Don't exceed 57 72 characters. 58 59 - The main description (the body) is normal prose and should use normal 60 punctuation and capital letters where appropriate. Normally, for patches 61 sent to a mailing list it's copied from there. 62 63 - When committing code on behalf of others use the --author option, e.g. 64 git commit -a --author "Joe Coder <joe@coder.org>" and --signoff. 65 66 67Owen Taylor 6813 Aug 1998 6917 Apr 2001 70 71Matthias Clasen 7231 Mar 2009 73