You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
59 lines
2.5 KiB
59 lines
2.5 KiB
|
|
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!
|
|
|