ballot

[Matthias Andree]

On Fri, 03 Jan 2003, David Relson wrote:

> The number of questions on the ballot has risen.
> 
> 1 - documentation re-organization - yay or nay

yay, but keep in mind we have constraints to observe. Some are imposed
by the BSD/SysV hier(7) documents, some are imposed by the Linux FHS
(less prevalent when "make install" installs into the same places), and
some are imposed by autoconf/automake (The feature to shuffle AC_LIBOBJ
source files to a separate directory is documented, but I can prove it
non-working.) It's fine with me to move all documentation sources to a
"doc" directory. We can also split the installed documentation into
"user" and "programmer" parts, I'd suggest
/usr[/local]/share/doc/[packages/]bogofilter/ for user-visible
documentation and the subdirectory
/usr[/local]/share/doc/[packages/]bogofilter/programmer/ for programmer
documentation.

I believe (barring other automake/autoconf bugs) we can move many of the
helper scripts (ylwrap, missing, config.*, depfiles) to an "aux"
subdirectory if we want that. I'd approve that.

> 2 - source code re-organization - yay or nay

Nay. We might do that at 1.0.0 release time, at which point we'd branch
the 1-0-0-stable branch, and reorganize the tree.

> 3 - next version - 0.9.2 or 1.0.0 or other

other: 0.10.0. Remember Zack Weinberg's article ("rant"). I don't think
we're 1.0.0 just yet.

We might want to dig out the TODO document and the old mails we
exchanged on the "what's needed for 1.0.0 issue", write up a summary,
kill the completed items and put milestones, with the next milestone
named 0.10.0, the following 0.11.0 and so on until we're satisfied with
the results. We have far too many changes to name them 0.9.2.

With hindsight, we should have named 0.9.1.1 0.9.2, 0.9.1.2 0.9.3 and we
should have done another 0.9.4 release with the bash1 "make check" fix
(If you're eager to do that now, feel free to do so and name it 0.9.2),
but that's only refining the good. bogofilter-0.9.1.2 has proven to be a
solid version which runs quite well, we'd only need to share the DB
issues out we've been observing, on Solaris (with faked locks), on Linux
(with tokens temporarily inaccessible), with DB (db_verify failures).

> 4 - algorithm for next version - graham, robinson (current), fisher 
> (proposed)

I have no Fisher experiences so far. Both Graham and Robinson have
worked quite well for me, it seems though that robinson does quite a
good job and it might even be better than graham, but I have no Fisher
figures yet.

HTH,
Matthias