Matthew T. O'Connor <matthew@zeut.net> said:
On Thu, 2004-07-08 at 03:43, Ilja Booij wrote:
"This all works for me, we want 2.0, let's bring out a Release
Candidate". And after that, things turned out to be broken and
we had to change a lot of things..
[snip]
I agree they are improvements and we do want to do them. I'm not
sure if we should add them now, or just release 2.0 and add them later.
There should only be changes to the user-visible interface into DBMail for
emergencies, for example adding configuration or command line options that
turn on modes which avert certain types of security breaches. That's the sort
of severity that is needed before we make drastic changes in a stable series.
[snip]
BTW, I think the command line changes are more important than the table
name changes. I would rather wait for the ability to specify a table
prefix in dbmail.conf
The default options in 2.1 should be compatible with the hardcoded options in
2.0. So If there's going to be configurable names, and we want 2.1 to be
out-of-the-box backwards compatible with 2.0, then we'd either have to set the
default prefix to no-prefix, or make some sensible default for 2.0.
I'm weighing long term annoyance for lots of people
vs. short term breakage for not so many people.
I understand, my only point is that if we still want to make these
changes, then we should have never said we were in RC mode, nor should
we even be in beta mode, since beta implies feature freeze.
Also, I think it's folly to assume a couple of changes make that much of
a difference. I think dbmail is already very good, yes it has some
warts, but they will get fixed. I also think it's folly to think that
once we release 2.0 a flood of users will suddenly flock to us.
That's a good point, and basing all actions on the assumption of a huge user
base is a mistake. However, I think that the bigger mistake is thinking that
nobody's waiting on us for a stable, easy to use release.
for 2.0, we'd only like to see 2 changes:
1. table names prefixed with 'dbmail_'
2. command line options sane.
Do we? If we change the table names, are we sure we will catch all the
code that references them? Are we sure that all the SQL will still
work? Do we then need to change the migration scripts? None of this is
impossible, but if we are going to thow these changes in and release in
a week, then we are asking for problems.
AFAIK, there has not yet been a concerted effort at release engineering. That
is, unpacking the tarball on a new machine, reading the README and the
INSTALL, using ./configure, make, and checking to see if it all works and
makes sense.
For the record, I am making a personal commitment to doing this type of
from-scratch testing on at least three machines.
Getting the database scripts right is absolutely critical. Besides that, a
missed 'dbmail_' somewhere in db.c is just a bug and calls for a quick point
release. Like any simple bug, fix the source, recompile, forget about it.
