code stability [was: Bogofilter 0.10.1.5]

[David Relson]

At 05:36 AM 2/2/03, Nick Simicich wrote:
>Compiles cleanly, make check runs cleanly.
>
>I noted that the release notes give a high level overview of the bug 
>changes between .1 and .5, pretty much lumping everything together.  I 
>decided to see for myself what the actual differences were, so I did a 
>diff between the versions and I saw a lot of changes.  Some, of course, 
>were lame little format changes when someone with different curly brace 
>styles worked on a module.  Others were real changes (although I agree 
>that they were minor).

Lumping comments together for the 5 betas was deliberate.  It was done to 
manage the size of the release notes.  Otherwise there would have been a 
lot of repetitions of

         Fixed bug that caused "Invalid buffer size message"
         Fixed bug that caused loop.
         Fixed database locking bug.
         Fixed minor parsing bug.
         Fixed bug killing html comments.
         Portability fix in regression test.
         etc.

>Changing the diff parameters to "-i -w -b -B -u -P" (reduces noise caused 
>by space differences, and accounts for new files) and filtering the output 
>through | grep '^\+[^+]' | wc -l gives "105" on the system I usually run 
>bogofilter on.  That is a lot of lines of code change, no, for something 
>almost stable?  (it is 107 when you grep -v '0\.10\.1').  If you just 
>untar the tar files, and you remove the limitations that hold you to *.c 
>or *.h files, it is about 107/264 lines.  Then again, that is going down - 
>1606 lines from 3 to 4 (including new test case data, like valgrind.  174 
>when you just consider *.c and *.h files. 185 lines difference from 2 to 
>3, with 139 of those lines in the *.c and *.h files.
>
>My question, is about the comment that changes are slowing down.
>139/174/107 does not seem to me to be that significant of a slowdown. 
>(185/1606/264 is likely to be bogus because of all of the non-programming 
>changes that are included.)

I think that change are slowing down.  However some of the late changes 
affected many lines of code.  For example, several of the late changes 
involved the size of numeric values in the wordlist.  Until people started 
building and testing on 64-bit processors nobody knew there was an 
issue.  The first round of changes fixed bogofilter so that the tests would 
work whether a long was 4 bytes or 8 bytes.  This changes a few lines of 
code.  Then the decision was made that the counts should _all_ be 4 bytes 
long.  This involved changing the code to use inttypes.h and uint32_t and 
changed many lines of code.  Then issues of header file names and defined 
types reared their ugly heads.  So more changes to configure.ac to 
determine sizeof(int), sizeof(long), ..., changes to the order of testing 
and including header files, etc.  A "simple" change turned out to cover 
several releases and many lines of code - all for the sake of portability.

I agree that lines of code changed is a metric of rate of change.  However 
it is not the only such metric.  The main goal for 0.10 was to include mime 
processing.   A late goal was the killing of html comments.  These goals 
have been achieved, though the code is not yet perfect.  I do think the 
rate of change has slowed down and that the current code is working well 
enough for a stable release.

I'm not saying that bogofilter is perfect in what it does.  There is room 
for enhancement.  However I do believe it is time for a release and that we 
can designate it as stable.

David