Guidelines

This is not meant to be a strict set of rules, but merely a emphasized suggestion, a SVN etiquette if you might.

Developers without commit rights

Submit a new bug in trac and send a mail to the mailing list containing a brief explanation and a link to the bug report. If you receive no feedback in the course of 15 days try insisting with another mailing list message.

Warning: mail list strips binary attachments and some clients fail to recognize *.patch and *.diff properly. This is common with GMail and other webmail. Before sending patches, ensure you have the following line in your /etc/mime.types:

text/x-diff  diff patch

Patch file format

Now that we're using SVN, patches are already in "unified" format, so nothing is really needed. Just use:

svn diff -x -up PATH > 0001-my-first-mod.patch

Even more helpful is you to review the patch contents and check if there is no redundant stuff or useless white space changes, You can also provide a diffstat and add comments to the patch (before the patch itself). The process summary is:

svn diff -x -up > 0001-my-first-mod.diff
less 0001-my-first-mod.diff # review!!!

$EDITOR 0001-my-first-mod.message # write your description
cat 0001-my-first-mod.message > 0001-my-first-mod.patch

diffstat 0001-my-first-mod.diff >> 0001-my-first-mod.patch
cat 0001-my-first-mod.diff >> 0001-my-first-mod.patch

mail 0001-my-first-mod.patch

It's good to keep 0001-my-first-mod.message as a subject line up to 72 chars, then a blank line and then the description body, breaking lines at 72chars (good for mail)

Warning: please check ECoding to know exact coding style before sending patches! It's quite unusual coding style and most people will send patches that will mess it up if our coding style is not followed. Run the script source:/trunk/SCRIPTS/check-patch.py before sending the patch.

New developers WITH commit rights

Depending on the type of commit you intend to make there are two paths to follow. If you feel confident about your patch, be it because you are a confident person or because the patch fixes a trivial problem, go ahead with your commit. But be warned, developers constantly breaking the build will have their commit rights removed.

If you don't feel confident, probably because your patch implements new functionality or API changes, simply follow the regular path. Submit a new bug in trac and send a mail to the mailing list containing a brief explanation and a link to the bug report. If you receive no feedback in the course of 15 days you are free to commit it without fear.

Warning: please check ECoding to know exact coding style before sending patches! It's quite unusual coding style and most people will send patches that will mess it up if our coding style is not followed.