rocklinux/Documentation/Developers/PATCHES

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 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
console 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 -p1 < patchfile' in the base directory.

    Patches created with 'cvs diff' or 'svn diff' and simmilar are also ok,
    as long as they are context diffs and can be applied with the the
    misc/archive/apply-patch.sh script.

 2. The Patch shouldn't contain any files which are automatically generated
    by ./scripts/Puzzle.

The script "./scripts/Create-Diff <old-dir> <new-dir>" can be used to
easily create patches conforming to 1. and 2.

 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. If a patch isn't two-lines self-describing, add a little comment and a
    properly formated CHANGELOG entry at the top of the patch file or the
    mail body.

 6. If you don't get any feedback and the patch doesn't show up in the
    snapshots after a week, resend the patch to the maintainer.

 7. Don't pack your patches to tar-files. That makes it much harder to open
    and read them in a mail-reader. Only compress a patch if it's _really_ big.

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

 9. Don't just send me the files you have been added or modified. Send me
    a patch against the ROCK Linux Sources (as described above).

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