FreeRADIUS InkBridge

Submitting patches via email

We strongly prefer to see patches via GitHub. Email should only be used when it is impossible to use GitHub.

1. diff -u

Use diff -u or diff -urN to create patches.

All changes to the source occur in the form of patches, as generated by diff(1). When creating your patch, make sure to create it in unified diff format, as supplied by the -u argument to diff(1). Patches should be based in the root source directory, not in any lower subdirectory.

To create a patch for a single file, it is often sufficient to do
SRCTREE=/home/user/src/freeradiusd/
MYFILE=src/modules/rlm_foo/foo.c

cd $SRCTREE
cp $MYFILE $MYFILE.orig
vi $MYFILE # make your change
diff -u $MYFILE.orig $MYFILE > /tmp/patch

To create a patch for multiple files, you should unpack a vanilla, or unmodified source tree, and generate a diff against your own source tree. For example:

MYSRC=/home/user/src/freeradiusd-feature/

gunzip freeradiusd-version.tar.gz
tar xvf freeradiusd-version.tar
diff -urN freeradiusd-version $MYSRC > ~/feature-version.patch

2. Select e-mail destination

If you are on the developers mailing list, send the patch there. freeradius-devel@lists.freeradius.org

Otherwise, send the patch to freeradius-users@freeradius.org

The developers need to be able to read and comment on the changes you are submitting. It is important for a developer to be able to quote your changes, using standard e-mail tools, so that they may comment on specific portions of your code.

For this reason, all patches should be submitting e-mail inline.

Do not attach the patch as a MIME attachment, compressed or not. Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your code. A MIME attachment also takes a bit more time to process, decreasing the likelihood of your MIME-attached change being accepted.

Compressed patches are generally rejected outright. If the developer has to do additional work to read your patch, the odds are that it will be ignored completely.

4. E-mail size

Large changes are not appropriate for mailing lists, and some maintainers. If your patch, exceeds 5Kb in size, you must submit the patch via GitHub instead.

5. Name the version of the server

It is important to note, either in the subject line or in the patch description, the server version to which this patch applies.