1 Patch guidelines

Procedures that should be followed when submitting patches for 

Evolution are available on 

http://projects.gnome.org/evolution/patch.shtml

Further information:

1.1 Subject Lines

If the patch addresses a specific bug in bugzilla.gnome.org, then the

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

this.

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.

2.3 Stable branches

Generally, any patch to the stable branch from non-core developers

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.