HACKING 2.35 KB
Newer Older
Not Zed's avatar
Not Zed committed
1 2
1 Patch guidelines

3 4 5
Procedures that should be followed when submitting patches for 
Evolution are available on 
http://projects.gnome.org/evolution/patch.shtml
Not Zed's avatar
Not Zed committed
6

7
Further information:
Not Zed's avatar
Not Zed committed
8

9
1.1 Subject Lines
Not Zed's avatar
Not Zed committed
10

11
If the patch addresses a specific bug in bugzilla.gnome.org, then the
Not Zed's avatar
Not Zed committed
12 13 14 15 16 17 18 19 20
bug number must be included in the subject line, preferably near the
beginning of the subject line.  A concise summary of the bug(s) being
addressed, should be the remainder of the subject.

It is unnecessary to add "[PATCH]", "patch" or similar to the subject
line, unless it is being cross-posted to other non-patch lists.

It is absolutely unnecessary to add "please consider", "please review",
or "seeking review", or similar, to the subject line.  Please do not do
Ettore Perazzoli's avatar
Ettore Perazzoli committed
21
this.
Not Zed's avatar
Not Zed committed
22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

Where the patch does not address a specific bug number, then the subject
line should simply be a concise summary of the problem/feature it
addresses.

In all cases the subject line should include the module(s) to which the
patch applies, and would generally match the component on the bug or
the top-level module directory (e.g. camel, mail, addressbook, use 'all'
for more than 3 or 4 modules).

2.2 Message Body

Patches should be attached as attachments, preferably as a single
diff, when possible, and the changes are related.  The diff must be in
unified diff format, "-up" is a suitable argument to give to "cvs
diff" (-p may be dropped if not supported by your diff).  If you have
added files, then -N should also be used, but if you are using cvs,
"cvs add" is needed, and requires write access to the repository.

If the patch does not address a specific bug, then the patch email
should describe which feature or problem it addresses.  If it does
address a specific bug, then further explanation beyond the bug
commentary is optional, although often convenient.

It would also be helpful to summarise the module to which it applies
in the message body.

In all cases you should include which branch, or branches, the patch
is intended to apply to.  If this is not given it will be assumed to
be the trunk (HEAD), and such patches will and must not be applied to
any stable branch without further approval.

54
2.3 Stable branches
Not Zed's avatar
Not Zed committed
55 56

Generally, any patch to the stable branch from non-core developers
57 58 59
must address a specific bug in bugzilla.gnome.org.  The patch should
also be attached to the bug in question.  The patch must not be
applied until reviewed.