On August 10, [EMAIL PROTECTED] said: > I am also (personally) not thrilled with the attitude of refusing to > support CVS Emacs. I understand the reasoning behind it---trying to > catch up with a moving target plus lack of resources.
My major gripe with trying to support CVS Emacs (or CVS XEmacs, for that matter) is simply that it's not stable (this has also applied to several dot releases of Emacs, in particular the 20.x series which seemed to break multibyte characters with almost every release). I get someone sending me a mail about a bug this week, and next week it's not a bug anymore because it was a bug in Emacs, not BBDB, and it's been fixed at source. Regardless of issues of moving targets or lack of resources, trying to maintain a complex piece of code on top of an unstable platform is a complete waste of time. Having said that, I don't go out of my way to avoid supporting CVS Emacs, but I do take exception to using new whizbang lisp features simply because they're available. If the existing lisp code does the job sufficiently well I see no reason to break it, and there's already far too much version-testing function-aliasing crap in BBDB without adding more to it. > It would be nice if an official policy regarding BBDB was stated > someplace. I disagree. Official policies are for products and politicians. BBDB is neither; BBDB is, and always has been, hackerware, and while much has been done to make it less menacing to those unfamiliar with lisp, it's still a rat's nest of surprises and dead ends and really, if you're doing anything non-trivial with it, you'll have to get your hands dirty with lisp at some point. My own "official policy", much as I hold that phrase in distaste, is that if you give me a reasonable patch (e.g. fixes a bug, implements a feature cleanly, etc.) then I will merge it in. If you give me an unreasonable patch (reformats code, reimplements existing code "in a better way", etc.) I will discard it, quite probably without comment. If you consistently provide good code, you get CVS write access; if, having gotten CVS write access, you consistently break things or otherwise annoy me, you lose CVS write access. I generally don't do feature requests unless someone's made a good stab at coding it up already, although some of the other CVS writers have done impressive work in this respect, and if you've got an entire file full of new self-encapsulated features (e.g. the bbdb-letters code that was recently discussed on the list) I will probably at least add it to the bits/ directory if I think it's not quite fit for BBDB proper. I don't object to maintaining BBDB; on the contrary, I volunteered for the job when noone else seemed to be interested. I do object to anything that makes it more of a chore than it already is. Which I think is a rough summary of what I've said above. And now, we return you to our regularly scheduled list traffic. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. "what have i become? / my sweetest friend everyone i know / goes away in the end" - NIN, "hurt" (the downward spiral) ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
