Following rules apply to writing commit messages in PLD CVS repository. They are mainly in charge in SPECS and SOURCES modules, but most of them should be used also in other modules. Always supply a meaningful commit message Remember: your commit message will be logged and saved in the spec file as well as sent to the commit-list. Lines in commit message should be wrapped before 80th column. Examples of valid messages are: "- spec adapterized" "- added working Source0 URL" "- completed docs" Examples of bad messages: "i'm bored today" "" Add a '- ' to your log messages ...so that the changelog looks nicer. Compare: Revision 1.4 1999/11/01 23:54:47 corleone - added static subpackage with statically linked zsh, - added BuildRequires rules, - added info and DESTDIR patches. to: Revision 1.2 1999/09/04 15:17:23 corleone Updated to 3.1.6 Added more macros Small fixes Remember: a dash with a space after it. Something like this looks ugly: Revision 1.4 2002/04/22 10:19:27 corleone - pl fixes Revision 1.3 2002/04/21 17:39:49 corleone -add pl description Try to be consistent. Never correct mistakes in the logs Unless: it's your own log message you want to correct a missing '-' at the beginning of a line you want to remove unnecessary empty lines But don't commit cosmetic changes in changelogs as the only changes in spec. Commit message like "- increased release" or "- release++" are wrong. You should always write number to which release was increased. This is because it should be clear for person reading just the changelog what changes was made between particular releases. Similarly for version numbers ("- updated to latest version" isn't very good commit message). Commit message like "- sources for foobar" when committing SOURCES/foobar-0.1.2.tar.gz also isn't very good idea. There are just two right messages for commits in SOURCES module regarding tarballs: output of md5sum, like: 9b65a7c19ef31a5dbc2f30627d1c3222 gcc-20020415.tar.gz text: "- outdated" Another bad idea is commit message with output of md5sum when committing patches or, heaven forbid, spec files. In case of patches you should mention: source (author and/or url) of patch (unless it is yourself, this is assumed default) what patch fixes if patch is modified version of something found in the net, you should mention both the original sources, and the fact, that you modified it In case of initial import of spec file you should mention where does the spec come from ("- from scratch", "- roughly based on spec from MDK; rewritten" are both OK). There is no need to cite Summary: there. Patch names should have format: PACKAGE-what-patch-fixes.patch. They should be in unified diff format (diff -urN original-tree/ fixed-tree/ is good way of preparing such beasts). Name should not contain version number. This is all true, unless patch is unmodified version of something that has URL. Leave it then as it stands.