[bogofilter-announce] Bogofilter-0.14.1 - New Current Release

[Matthias Andree]

David Relson <relson at osagesoftware.com> writes:

> Bogofilter version 0.14.1 has been released on SourceForge,
> http://sourceforge.net/projects/bogofilter.
>
> 0.14.1 - Adds token degeneration capability (use "bogofilter -h" for
> help) and changes exit codes from 0=spam, 1=ham, and 2=error to 0=spam,
> 1=ham, 2=unsure, and 3=error; and fixes several minor bugs with 0.14.0.1
>
> See files NEWS-0.14 and RELEASE.NOTES-0.14 for the details.
>
> 			       =================
> 				BOGOFILTER NEWS
> 			       =================
>
> 0.14.1	2003-07-31
>
> * Implemented named exitcodes, with Unsure having its own value (2)
>    and changing the value for error from 2 to 3.

This isn't the right thing to do. We cannot change established exit
codes at will. 2 was error, and 2 must remain "error". There is no
reason why unsure cannot be "3". If the command line allows to rearrange
exit code mappings, that's fine, but the default must remain what it has
been over the past year. Tomorrow someone maps "unsure, maybe spam" and
"unsure, maybe ham" to 3 and 4 and error moves from 2 over 3 to 5,
breaking scripts and existing setups again. This was discussed on
bogofilter-dev, and I haven't seen any counter evidence to the
suggestion to use 3 for "unsure".

Bogofilter suffers from a severe optionitis (proliferation of options),
we have options to cater for any personal preference, whether there is a
technical need or no.

WE NEED NO OPTIONS TO CONFIGURE IF SOMEONE WANTS Y/N/? OR S/H/U OR 1/0/?.

All these options, particularly if changing established behaviour, make
supporting the software difficult and prone to failure. This violates
the simplest principle: keep it simple, stupid.

MOST of the code growth of the past months has gone into convenience
options that aren't necessary. The core functionality except for the
lexer has hardly changed, so the next directives (before 1.0) are
throwing all that accumulated cruft out again, like removing half of the
options. Please remember that ESR started this project, and his new book
mentions some of the principles that we should adhere to.

There is really no need for bogofilter to understand different mailbox
formats, this is something a wrapper can do that we will ship.

There is no need either for convenience changes to let the user
configure exit codes, and we shouldn't offer support for too many ways
to run bogofilter either. Bogofilter's duty is to evaluate spam, not to
accomodate taste or integrate with everything. Software needs to be
adapted when integrated into a system at large, this has always been the
case and will be the case.

We should refactor the code so that we have a libbogofilter that other
software (bogofilter and bogoutil for a start, later a client-server
model) can use, then everybody can write his own wrapper interface,
possibly in Perl, to accomodate his needs. Such stuff does not belong
into bogofilter itself.

We _NEED_ to cut the option count to half of what it is now. We'll have
less code paths and easier debugging.


Putting on the packager's hat: I will not ship or approve updates for
bogofilter on FreeBSD unless this is solved.

-- 
Matthias Andree