The ROCK Linux Patch Guide
==========================

In order to make applying patches as efficient as possible, submitted
patches should be in the format described here. I (and some maintainers
of subsystems) might be refusing patches if they don't conform to this
document.

Please use the ROCK Linux Submaster server to commit patches:

	https://www.rocklinux.net/submaster/

If you send patches to the mailing list, make sure that someone else is
putting it into submaster for you. Otherwise you risk that you patch might
be ignored or get lost.

More information about submaster can be found at

	http://www.rocklinux.org/submaster.html

The package also contains a command-line tool to easily create patches and
send them to the submaster server.

If you really need to send patches per mail, please put the string [PATCH]
at the beginning of the Mail Subject. It might not be seen if the word isn't
part of the first few characters, since many mail clients do only show the
start of the subject in the mail index.

 0. DON'T SEND UNTESTED PATCHES WITHOUT POINTING OUT CLEARLY THAT THEY ARE
    UNTESTED AND DON'T EXPECT UNTESTED PATCHES TO GET APPLIED. In cases of
    package updates, etc. it's already enought to test if the package still
    builds fine in a more or less generic configuration.

 1. Patches should be in the the unified- or context-format. We prefer
    unified diffs. It should be possible to apply the patch with the
    command 'patch -p0 < patchfile' or 'patch -p1 < patchfile' in the
    base directory.

 2. The header of the patch file (the part before the patch itself starts) should
    contain a short description of the patch in the format:

--snip--
Author Name:
	What has been done
	What has also been done
--snip--

    When updating packages use the phrase "Updated m4-1.4" or "Updated m4 (1.4)".
    Never write descriptions such as "Fixed a ugly bug" or "Updated 1.4" without
    even naming the subsystem or package effected.

 3. The patch should be against one of the latest development snapshots or
    (even better) the relevant Revision Control System used for the source
    tree.

 4. One patch should solve only one issue. If you have multiple (independent)
    fixes, send multiple patches.

 5. Inform the responsible maintainer when you start working on a problem to
    make sure you are not doing duplicate work.

 6. NEVER SEND TAR-FILES WHICH ARE REPLACING THE FILES YOU HAVE MODIFIED
    AND/OR ARE ADDING NEW FILES! ALWAYS SEND PATCHES AS DESCRIBED ABOVE!