Aaron Stone wrote:
Ilja Booij <[EMAIL PROTECTED]> said:
I don't think we should do this right now.
[snip]
Aaron Stone wrote:
the people affected by it are those following the bleeding edge
of rc's and CVS, folks who are more likely to understand the
usefulness of a change like this.
[snip]
Matthew T. O'Connor <matthew@zeut.net> said:
Release candidates are not supposed to be bleeding edge!
I agree with you, and (Ilja better warm up your flamethrower...) I don't think
that DBMail was ready for the release candidate phase when it started. My take
on it was that Ilja was looking to put the squeeze onto the broken parts of
the delivery chain and get me to start making it work consistently. As it
turned out, I had a lot of wrong assumptions and Ilja saved the day.
I guess the process on my side was something like:
"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..
So.. what it came down to is lack of planning and lack of good testing
on my side.
I guess only our last two RC's can be really called Release Candidates.
<>
Now that we've stablized the core, I feel like we're out of beta, but not
quite ready for release because of a number of annoying details that
should be
worked out before we foist the annoyances upon the unwashed masses.
Like inconsistent binary names, bizarre command lines and funky table
names.
These are all things which are easily fixed, but represent trivial
breakages
of backwards compatibility. Clearly this isn't something that can be
done in a
release series, so we can't do it after 2.0, and yet they're annoying
enough
that I don't think we'll much enjoy supporting them for the duration
of the
2.1 development cycle and release schedule, so we have to do it now.
I'm weighing long term annoyance for lots of people
vs. short term breakage for not so many people.
OK. I was trying to stop ourselves from changing these things quickly
when we don't
want the changes anymore. On the other hand, I do see the usefulness of
this...
So....:
for 2.0, we'd only like to see 2 changes:
1. table names prefixed with 'dbmail_'
2. command line options sane.
Am I right? I don't see anything else that needs to be done at the
moment (except for fixing the
occasional bug.
<>
[snip]
... meaning feature freeze long since passed, all known bugs squashed,
ready for release barring newly exposed problems.
We kinda went at this sideways. We froze temporarily so that we could squash
bugs, but we really need to have a selective thaw cycle for the annoyances.
Big projects do sometimes take changes at this stage, but only moderated
through the release manager. That's why I posted my patches to the mailing
list for Ilja to review instead of just committing them willy nilly.
I agree with Matthew that my way of releasing RC's has not been good. I
new at this kind of thing, learning as we go along (if anybody's got
some links to some on-line articles or books on open source software
management that are useful to read, please point me to them). I've
learned a lot about DBMail, e-mail, autoconf etc in the past year.
Because of this, new things for DBMail came along constantly, and 2.0
became a moving target. 2.1 should be less of a moving target, with a
new set of features that should be fixed from early on.
Ilja
--
Ilja Booij
IC&S B.V.
Stadhouderslaan 57
3583 JD Utrecht
www.ic-s.nl
T algemeen: 030 6355730
T direct: 030 6355739
F: 030 6355731
E: [EMAIL PROTECTED]
