-------- Original-Nachricht -------- > Datum: Fri, 11 Apr 2008 16:18:33 +0300 > Von: Ion-Mihai Tetcu <[EMAIL PROTECTED]> > An: [EMAIL PROTECTED] > CC: dspam-dev@lists.nuclearelephant.com > Betreff: [dspam-dev] Dspam CVS, packaging, QA
> 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 ;-))! > Yeah. I made a mistake but the CHANGELOG has my changes: [20080310:0556] steveb: Allow daemon to listen to specific TCP host User-configurable preference ServerHost added (set to '127.0.0.1') to allow using specific TCP host when running in daemon mode. Not specifying ServerHost will bind to all available interfaces when running in daemon mode and using TCP sockets. > 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 -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
