Hi,
[ This mail got to long, I'll deal with packaging & QA in a second one ] For personal reasons I haven't been able to be as active as I used to be here in the last year or so, but now I hope that's over and I'm back with a vengeance :-) As you might know I'm a FreeBSD committer and, among other ports, I maintain 2 dspam ports, mail/dspam[1] and mail/dspam-devel[2]. mail/dspam is supposed to be the stable version while mail/dspam-devel is usually based on a cvs snapshot I make (or the latest release for a shot time after the release date for QA purposes if the changes since the last snapshot weren't tested enough). As a general policy we (FreeBSD) try to keep the local changes at minimum, trying to push our patches upstream. This has worked very well with Jonathan who also was very responsive with the problems that for one reason or another manifested only on FreeBSD. I hope we can achieve the same with you (people form Sensory Networks). One of the tools we packagers, probably more that regular users, relay on is the CVS. Today, in preparation for a new snap for -devel port, I tried to browse the CVS logs; as Mr. Spock would say their content was less that fascinating ;-). Bellow there are a few suggestions that should help both us users and you code maintainers. (I do realise it took us some hundred of committers 13+ years of maintaining OS sources, 18.000+ third party applications, etc. in publicly accessible CVS to get us to these rules[4] and that there's a big difference between our and dspam's numbers but why test the same wall's solidity with own head when we already did than, repeatedly ;-D ?) Good commit messages are important. They tell others why you did the changes you did, not just right here and now, but months or years from now when someone wonders why some seemingly illogical or inefficient piece of code snuck into your source file. 1. Empty commit logs are EVIL (hi steveb ;-))! An empty commit message negates half of the reason one uses a revision control system: the 'why' part from 'what changed between revisions and why'. Since we're all humans we have our CVS enforce this [3]. 2. Commit messages should be clear, concise and provide a reasonable summary to give an indication of what was changed and why. Commit messages should provide enough information to enable a third party to decide if the change is relevant to them and if they need to read the change itself. - "Update round for Feb. 1st, 2008" tells me what exactly ? 3. Please avoid committing several unrelated changes in one go. It makes merging difficult, and also makes it harder to determine which change is the culprit if a bug crops up. Please avoid committing changes to multiple files in one go with a generic, vague message. Instead, commit each file (or small, related groups of files) with tailored commit messages. - NN "round of patches for 3.8.1" - the mega commits based on gentoo's patches 4. Please avoid committing style or whitespace fixes and functionality fixes in one go. It makes merging difficult, and also makes it harder to understand just what functional changes were made. 5. Please use the -f option if you realize that you left out important information from the commit message. Finally to other suggestions, merely for our convenience: - Put a link to the CVS web interface on the download page http://dspam.nuclearelephant.com/download.shtml - set up a dspam-cvs mailing list with the commit messages; this will both keep us better informed about what's new and easily allow us to trigger builds on our package clusters/tinderboxes/... (more on this in my next mail). [1] http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/dspam/ [2] http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/dspam-devel/ [3] http://www.freebsd.org/cgi/cvsweb.cgi/CVSROOT-src/logcheck?rev=1.24;content-type=text%2Fx-cvsweb-markup [4] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/cvs.operations.html#AEN639 Thank you, -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> [EMAIL PROTECTED], PGP Key ID 057E9F8B493A297B
signature.asc
Description: PGP signature
