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.
65 lines
2.5 KiB
65 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 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 your patches might
|
|
be ignored or get lost.
|
|
|
|
More information about submaster can be found at
|
|
|
|
http://www.rocklinux.org/submaster.html
|
|
|
|
This page 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 enough 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!
|
|
|