Clifford Wolf:

Documentation/Developers/PATCHES

@@ -7,10 +7,25 @@ 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.
+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
@@ -19,17 +34,21 @@ index.
 
  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.
+    command 'patch -p0 < patchfile' or '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 header of the patch file (the part before the patch itself starts) should
+    contain a short description of the patch in the format:
 
- 2. The Patch shouldn't contain any files which are automatically generated
-    by ./scripts/Puzzle.
+--snip--
+Author Name:
+	What has been done
+	What has also been done
+--snip--
 
-The script "./scripts/Create-Diff <old-dir> <new-dir>" can be used to
-easily create patches conforming to 1. and 2.
+    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
@@ -38,22 +57,9 @@ easily create patches conforming to 1. and 2.
  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
+ 5. 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
+ 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!