FYI. Rawhide now contains a snapshot of spamassassin-3.0.0, which will
be updated next week when the official pre-release happens. I encourage
all spamassassin users to rebuild the rawhide spamassassin SRPM for use
on FC1 or FC2 in order to provide production testing, and report bugs in
upstream Bugzilla. I personally have been using 3.0.0 svn snapshots on
my personal server for a few weeks now, and it has been much better than
spamassassin-2.63 for me.
Warren Togami
wtogami@xxxxxxxxxx
-------- Original Message --------
Subject: 3.0.0 schedule
Date: 28 May 2004 17:41:24 -0700
From: Daniel Quinlan <quinlan@xxxxxxxxxxxx>
Reply-To: quinlan@xxxxxxxxxxxx
To: spamassassin-dev@xxxxxxxxxxxxxxxxxxxx
So, here's the new schedule, based on Theo's last schedule:
(a) bug squashing is not part of schedule; this can and should be
scheduled independently
(b) there is no concept of "all bugs" any more, only "critical bugs"
(c) warning people about mass-check runs is also decoupled as that can
be done independently -- we can warn people now, even
(d) critical bugs had better darn well show up in red in my bugzilla
screen (that is, "Severity" field set to "critical") or the bug
doesn't count as critical.
feature freeze:
05/31: feature freeze, enter Review-then-Commit mode at 0900 UTC to
enforce feature freeze
pre-release cycle:
06/03: first pre-release
do {
3 to 7 days of testing of pre-release
issue new pre-release
} while (critical bugs found in testing)
mass-check cycle:
day 0: announce mass-check run 1 (sets 0 and 1), run 7 days
day +7: generate scores, etc.
day +9: new pre-release with new scores, announce mass-check run 2
(sets 2 and 3), run 7 days
day +11: generate scores, etc.
release-candidate cycle:
day 0: release 3.0.0-rc1
do {
3 to 7 days of testing of release candidate
issue new release candidate
} while (critical bugs found in testing)
day ?: issue 3.0.0-final
------------------------------------------------------------------------
RATIONALE:
First, we need R-T-C to have the feature freeze. Second, my experience
is that we actually move faster once we enter R-T-C mode because
everyone is following development closer.
We should not try to get everything done or close every bug before
moving forward with pre-releases (which must precede the mass-checks to
get the bugs out) because we'll always have bugs being added. 2.63 is
not as good as 3.0, so let's release and help out our users.
So, no more bug squashing events, no more delays, let's enter R-T-C mode
on Monday and do a pre-release next week. WE ARE READY.
Also, if someone wants to replace the scores, then you have a week.
Open a bug. ;-)
I believe tying everything together in the schedule is adding delays and
making it easier to slip more and more stuff into the release. We never
had to lock-step things before, we just reviewed the open bugs at each
stage of the simple schedule and decided whether or not we were ready to
proceed to the next step or if we had to cut a new pre/rc release. It's
how most open source projects work. Assigning dates far out in the
future is pretty pointless and just makes things frustrating.
As you can see, I've attempted to streamline the schedule, for example,
by allowing for as little as 3 days of testing (if a bug can be verified
as fixed quickly) so we can plow through rather than stay stuck in the
mud. I limited things to 3 days, though, so we don't issue new releases
every day or every other day.
Finally, since we're not in R-T-C mode yet, I'm calling this the 3.0.0
schedule. If you want to veto...
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
