[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Spamassassin [Fwd: 3.0.0 schedule]



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

-------- Original Message --------
Subject: 3.0.0 schedule
Date: 28 May 2004 17:41:24 -0700
From: Daniel Quinlan <quinlan pathname com>
Reply-To: quinlan pathname com
To: spamassassin-dev 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/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]