mirror of the now-defunct rocklinux.org
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

  1. The ROCK Linux Patch Guide
  2. ==========================
  3. In order to make applying patches as efficient as possible, submitted
  4. patches should be in the format described here. I (and some maintainers
  5. of subsystems) might be refusing patches if they don't conform to this
  6. document.
  7. Please use the ROCK Linux Submaster server to commit patches:
  8. https://www.rocklinux.net/submaster/
  9. If you send patches to the mailing list, make sure that someone else is
  10. putting it into submaster for you. Otherwise you risk that your patches might
  11. be ignored or get lost.
  12. More information about submaster can be found at
  13. http://www.rocklinux.org/submaster.html
  14. This page also contains a command-line tool to easily create patches and
  15. send them to the submaster server.
  16. If you really need to send patches per mail, please put the string [PATCH]
  17. at the beginning of the Mail Subject. It might not be seen if the word isn't
  18. part of the first few characters, since many mail clients do only show the
  19. start of the subject in the mail index.
  20. 0. DON'T SEND UNTESTED PATCHES WITHOUT POINTING OUT CLEARLY THAT THEY ARE
  21. UNTESTED AND DON'T EXPECT UNTESTED PATCHES TO GET APPLIED. In cases of
  22. package updates, etc. it's already enough to test if the package still
  23. builds fine in a more or less generic configuration.
  24. 1. Patches should be in the the unified- or context-format. We prefer
  25. unified diffs. It should be possible to apply the patch with the
  26. command 'patch -p0 < patchfile' or 'patch -p1 < patchfile' in the
  27. base directory.
  28. 2. The header of the patch file (the part before the patch itself starts) should
  29. contain a short description of the patch in the format:
  30. --snip--
  31. Author Name:
  32. What has been done
  33. What has also been done
  34. --snip--
  35. When updating packages use the phrase "Updated m4-1.4" or "Updated m4 (1.4)".
  36. Never write descriptions such as "Fixed a ugly bug" or "Updated 1.4" without
  37. even naming the subsystem or package effected.
  38. 3. The patch should be against one of the latest development snapshots or
  39. (even better) the relevant Revision Control System used for the source
  40. tree.
  41. 4. One patch should solve only one issue. If you have multiple (independent)
  42. fixes, send multiple patches.
  43. 5. Inform the responsible maintainer when you start working on a problem to
  44. make sure you are not doing duplicate work.
  45. 6. NEVER SEND TAR-FILES WHICH ARE REPLACING THE FILES YOU HAVE MODIFIED
  46. AND/OR ARE ADDING NEW FILES! ALWAYS SEND PATCHES AS DESCRIBED ABOVE!