HACKING

   1 1 Patch guidelines
   2
   3 Procedures that should be followed when submitting patches for
   4 Evolution are available on
   5 http://projects.gnome.org/evolution/patch.shtml
   6
   7 Further information:
   8
   9 1.1 Subject Lines
  10
  11 If the patch addresses a specific bug in bugzilla.gnome.org, then the
  12 bug number must be included in the subject line, preferably near the
  13 beginning of the subject line.  A concise summary of the bug(s) being
  14 addressed, should be the remainder of the subject.
  15
  16 It is unnecessary to add "[PATCH]", "patch" or similar to the subject
  17 line, unless it is being cross-posted to other non-patch lists.
  18
  19 It is absolutely unnecessary to add "please consider", "please review",
  20 or "seeking review", or similar, to the subject line.  Please do not do
  21 this.
  22
  23 Where the patch does not address a specific bug number, then the subject
  24 line should simply be a concise summary of the problem/feature it
  25 addresses.
  26
  27 In all cases the subject line should include the module(s) to which the
  28 patch applies, and would generally match the component on the bug or
  29 the top-level module directory (e.g. camel, mail, addressbook, use 'all'
  30 for more than 3 or 4 modules).
  31
  32 2.2 Message Body
  33
  34 Patches should be attached as attachments, preferably as a single
  35 diff, when possible, and the changes are related.  The diff must be in
  36 unified diff format, "-up" is a suitable argument to give to "cvs
  37 diff" (-p may be dropped if not supported by your diff).  If you have
  38 added files, then -N should also be used, but if you are using cvs,
  39 "cvs add" is needed, and requires write access to the repository.
  40
  41 If the patch does not address a specific bug, then the patch email
  42 should describe which feature or problem it addresses.  If it does
  43 address a specific bug, then further explanation beyond the bug
  44 commentary is optional, although often convenient.
  45
  46 It would also be helpful to summarise the module to which it applies
  47 in the message body.
  48
  49 In all cases you should include which branch, or branches, the patch
  50 is intended to apply to.  If this is not given it will be assumed to
  51 be the trunk (HEAD), and such patches will and must not be applied to
  52 any stable branch without further approval.
  53
  54 2.3 Stable branches
  55
  56 Generally, any patch to the stable branch from non-core developers
  57 must address a specific bug in bugzilla.gnome.org.  The patch should
  58 also be attached to the bug in question.  The patch must not be
  59 applied until reviewed.