CONTRIBUTING.md

   1 GLib is part of the GNOME git repository. At the current time, any
   2 person with write access to the GNOME repository, can make changes to
   3 GLib. This is a good thing, in that it encourages many people to work
   4 on GLib, and progress can be made quickly. However, GLib 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 GLib that has been built up over the years, we'd like to ask
   8 people committing to GLib 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 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
  26 1) Ask _first_.
  27
  28 2) You are expected to produce a meaningful commit message.
  29    Changes without a sufficient commit message will be reverted. See below for
  30    the expected format of commit messages.
  31
  32 Notes:
  33
  34 * When developing larger features or complicated bug fixes, it is
  35   advisable to work in a branch in your own cloned GLib repository.
  36   You may even consider making your repository publically available
  37   so that others can easily test and review your changes.
  38
  39 * The expected format for git commit messages is as follows:
  40
  41 === begin example commit ===
  42 Short explanation of the commit
  43
  44 Longer explanation explaining exactly what's changed, whether any
  45 external or private interfaces changed, what bugs were fixed (with bug
  46 tracker reference if applicable) and so forth. Be concise but not too brief.
  47 === end example commit ===
  48
  49   - Always add a brief description of the commit to the _first_ line of
  50     the commit and terminate by two newlines (it will work without the
  51     second newline, but that is not nice for the interfaces).
  52
  53   - First line (the brief description) must only be one sentence and
  54     should start with a capital letter unless it starts with a lowercase
  55     symbol or identifier. Don't use a trailing period either. Don't exceed
  56     72 characters.
  57
  58   - The main description (the body) is normal prose and should use normal
  59     punctuation and capital letters where appropriate. Normally, for patches
  60     sent to a mailing list it's copied from there.
  61
  62   - When committing code on behalf of others use the --author option, e.g.
  63     git commit -a --author "Joe Coder <joe@coder.org>" and --signoff.
  64
  65
  66 Owen Taylor
  67 13 Aug 1998
  68 17 Apr 2001
  69
  70 Matthias Clasen
  71 31 Mar 2009