mirror of
https://gitlab.gnome.org/GNOME/nautilus
synced 2024-11-05 16:04:31 +00:00
b503e4fe8f
2003-05-05 Alexander Larsson <alexl@redhat.com> * HACKING: Add some text about patch submission.
49 lines
2.1 KiB
Text
49 lines
2.1 KiB
Text
Hacking on Nautilus
|
|
-------------------
|
|
|
|
The Nautilus source tree is available from GNOME cvs (cvs.gnome.org) and
|
|
in releases on the GNOME FTP site
|
|
(http://ftp.gnome.org/pub/GNOME/sources/nautilus/).
|
|
|
|
If you plan to hack on Nautilus, please make sure you work from the
|
|
CVS version. The CVS version can be checked from the GNOME cvs server.
|
|
See http://developer.gnome.org/tools/cvs.html for details on how to get
|
|
started with GNOME CVS.
|
|
|
|
If you want to contribute in development discussions, please send mail
|
|
to the nautilus mailing list: <nautilus-list@gnome.org>. Archives and
|
|
subscription information are available at
|
|
http://mail.gnome.org/mailman/listinfo/nautilus-list
|
|
|
|
|
|
Submitting Patches
|
|
------------------
|
|
|
|
If you've been working on a change to Nautilus and want to propose it
|
|
for inclusion, you have to generate a patch and submit it for review
|
|
by the maintainers.
|
|
|
|
Patches should be made with 'cvs diff -pu >patch' and should conform to
|
|
Nautilus coding style as described in docs/style-guide.html. We are
|
|
pretty strict about coding style, so please make sure you follow the
|
|
style guide to avoid unnecessary work on both sides when reviewing the
|
|
patch.
|
|
|
|
The best way to submit a patch for review is to post it on the mailing
|
|
list. That way everyone sees it and can take part in the following
|
|
discussion about it. Sometimes people also attach patches to bugs in
|
|
bugzilla (http://bugzilla.gnome.org, product 'nautilus'). If you do
|
|
this, please send a mail to the list saying you did so, because it is
|
|
very easy for the bugzilla email to get lost in all the bugzilla
|
|
reports, and only the people CCd on the bug can partake in the
|
|
discussion.
|
|
|
|
The Nautilus maintainers do their best to review patches and help
|
|
developers that want to work on something, however we are often
|
|
swamped in work and can miss an email or just forget to answer
|
|
it. Don't be afraid of reposting your patches after a while, or poking
|
|
us about the status of them.
|
|
|
|
Also, if you're planning to do large changes, please take them up for
|
|
discussion on the list first. If you get feedback early it is much
|
|
easier to integrate it into your work.
|