Spamassassin [Fwd: 3.0.0 schedule]

[Warren Togami]

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 at redhat.com

-------- Original Message --------
Subject: 3.0.0 schedule
Date: 28 May 2004 17:41:24 -0700
From: Daniel Quinlan <quinlan at pathname.com>
Reply-To: quinlan at pathname.com
To: spamassassin-dev at incubator.apache.org

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/