HACKING

   1 Hacking on Nautilus
   2 -------------------
   3
   4 The Nautilus source tree is available from GNOME svn (svn.gnome.org) and
   5 in releases on the GNOME FTP site
   6 (http://ftp.gnome.org/pub/GNOME/sources/nautilus/).
   7
   8 If you plan to hack on Nautilus, please make sure you work from the
   9 SVN version. The SVN version can be checked from the GNOME svn server.
  10 See http://developer.gnome.org/tools/svn.html for details on how to get
  11 started with GNOME SVN.
  12
  13 If you want to contribute in development discussions, please send mail
  14 to the nautilus mailing list: <nautilus-list@gnome.org>.  Archives and
  15 subscription information are available at
  16 http://mail.gnome.org/mailman/listinfo/nautilus-list
  17
  18
  19 Submitting Patches
  20 ------------------
  21
  22 If you've been working on a change to Nautilus and want to propose it
  23 for inclusion, you have to generate a patch and submit it for review
  24 by the maintainers.
  25
  26 Patches should be made with 'svn diff --diff-cmd diff -x -up >patch'
  27 and should conform to Nautilus coding style as described in
  28 docs/style-guide.html. We are pretty strict about coding style, so
  29 please make sure you follow the style guide to avoid unnecessary
  30 work on both sides when reviewing the patch.
  31
  32 The best way to submit a patch for review is to post it on the mailing
  33 list. That way everyone sees it and can take part in the following
  34 discussion about it. Sometimes people also attach patches to bugs in
  35 bugzilla (http://bugzilla.gnome.org, product 'nautilus'). If you do
  36 this, please send a mail to the list saying you did so, because it is
  37 very easy for the bugzilla email to get lost in all the bugzilla
  38 reports, and only the people CCd on the bug can partake in the
  39 discussion.
  40
  41 The Nautilus maintainers do their best to review patches and help
  42 developers that want to work on something, however we are often
  43 swamped in work and can miss an email or just forget to answer
  44 it. Don't be afraid of reposting your patches after a while, or poking
  45 us about the status of them.
  46
  47 Also, if you're planning to do large changes, please take them up for
  48 discussion on the list first. If you get feedback early it is much
  49 easier to integrate it into your work.
  50
  51 If your patch adds non-trivial strings, please ask for a string review
  52 from the i18n team before committing the changes. Strings should avoid
  53 contractions, and stay consistent with other strings already in Nautilus.
  54 Please reuse strings within Nautilus where it makes sense to do so.