You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Theo Van Dinter <fe...@kluge.net> on 2004/04/21 05:35:06 UTC
New proposed 3.0.0 release schedule
On Tue, Apr 20, 2004 at 03:28:56PM -0400, Theo Van Dinter wrote:
> I set the default milestone to 3.1.0. I'll post a proposal schedule
> later today.
Here's what I came up with. These are meant to be guidelines, not
hard dates. This schedule has a release in 10 weeks. I'd really like
to beat that. Depending on schedules, we can probably move up the code
related work. The release related stuff is pretty much the amount of
time it usually takes though.
CODE RELATED:
04/20: DONE - get bugzilla prioritized and either close/punt stuff
we're not going to get to to 3.1. We will need to get agressive about
some tickets -- for instance: we can't avoid all FPs, so if they don't
happen often and if it's not easy to fix, accept it, close the ticket,
and move on. Get open 3.0 tickets down to around 50.
04/22: feature freeze -- no more adding enhancements to 3.0 w/out vote
04/28: do bug squashing event for as many remaining open tickets as
possible. I assume there'll still be a few major ones open.
05/12: all tickets should be finished and closed. all testing rules
should be promoted or removed. do testing to make sure the mass-checks
will be smooth.
RELEASE RELATED:
05/07: warn people that mass-check runs will be starting shortly
05/17: announce mass-check run 1 (sets 0 and 1), run until 05/24.
enter R-T-C mode.
05/26: generate scores, etc.
05/31: announce mass-check run 2 (sets 2 and 3), run until 06/11.
06/13: generate scores, etc.
06/15: release 3.0.0rc1 -- fix bugs that come up, do polishing, etc.
release other 3.0.0rc as appropriate.
06/30: planned release of 3.0.0-final
Thoughts, comments?
--
Randomly Generated Tagline:
"If we can't keep this sort of thing out of the kernel, we might as well
pack it up and go run Solaris." - Larry McVoy
Re: New proposed 3.0.0 release schedule
Posted by Theo Van Dinter <fe...@kluge.net>.
On Wed, Apr 21, 2004 at 01:42:59PM -0500, Michael Parker wrote:
> > 04/22: feature freeze -- no more adding enhancements to 3.0 w/out vote
> I have 2 features I'd like to get in but won't quite have them
> finished by 4/22.
If you have/make a ticket for those, and put them in the 3.0 queue,
that'll be fine.
My plan for the "feature freeze" was basically to not add to the number
of enhancements already on the table -- so don't put any new enhancement
tickets in the 3.0 queue, and don't work on enhancements that aren't
already covered by a ticket in the 3.0 queue, without getting approval
via vote that the enhancement can go into 3.0.
--
Randomly Generated Tagline:
And in the limiting case where the optimizer is completely broken because
it's not implemented yet, we get to work around that too. Optionally...
-- Larry Wall in <20...@wall.org>
Re: New proposed 3.0.0 release schedule
Posted by Michael Parker <pa...@pobox.com>.
On Tue, Apr 20, 2004 at 11:35:06PM -0400, Theo Van Dinter wrote:
>
> 04/22: feature freeze -- no more adding enhancements to 3.0 w/out vote
>
I have 2 features I'd like to get in but won't quite have them
finished by 4/22.
1) Bayes Optimizations - 90% done
It includes a db version change, begins using hashes for tokens,
will require an import for old dbs. Import won't be supported for
the SQL side since it can't be done on the fly.
The SQL code is now faster than the DB_File code for scanning (w/
auto-learn).
2) Backup/Restore Bayes DBs - 50% done
Wholesale backup of a bayes DB and the ability to restore. This
could in theory do away with the import functionality since you
would just backup, clear, upgrade SA, and then restore the DB. It
also helps folks jumpstart their SQL bayes dbs.
I believe 1 is a must, 2 is iffy but would be incredibly handy in the
future.
Michael
Re: New proposed 3.0.0 release schedule
Posted by Duncan Findlay <du...@debian.org>.
On Tue, Apr 20, 2004 at 11:22:45PM -0700, Daniel Quinlan wrote:
> Duncan Findlay <du...@debian.org> writes:
>
> > Minor nitpick: I think you mean sets 0 and 2 (i.e. no net with and
> > without bayes)
>
> mass-check run 1 is for the non-bayes sets. A single --net mass-check
> is sufficient since you can just strip out the network results and
> generate both of the no-net sets (sets 0 and 1).
Right. I'd forgotten about the need for Bayes to have good scores. (I
did remember that you cant run 2 and 3 with one command)
> >> 05/26: generate scores, etc.
> >>
> >> 05/31: announce mass-check run 2 (sets 2 and 3), run until 06/11.
> >
> > Again: sets 1 and 3 (net with and without bayes)
>
> mass-check run 2 is for with the bayes sets. The first set of scores is
> needed to do accurate autolearning for _these_ runs. It *does* require
> two separate mass-check commands since different sets of scores are
> being used for auto-learning.
Ah... that's where my confusion was. I remembered that we need 3
mass-checks but I couldn't remember exactly which ones. And I agree,
they can be done simultaneously.
> Maybe this should be documented since it seems like we end up
> rediscussing it every release.
We all know we're bad at documenting stuff ;-)
How about we document this in the Wiki perhaps under:
http://wiki.apache.org/spamassassin/DevelopmentStuff
(Any volunteers...?)
--
Duncan Findlay
Re: New proposed 3.0.0 release schedule
Posted by Daniel Quinlan <qu...@pathname.com>.
Theo Van Dinter wrote:
>> RELEASE RELATED:
>>
>> 05/07: warn people that mass-check runs will be starting shortly
>>
>> 05/17: announce mass-check run 1 (sets 0 and 1), run until 05/24.
>> enter R-T-C mode.
Duncan Findlay <du...@debian.org> writes:
> Minor nitpick: I think you mean sets 0 and 2 (i.e. no net with and
> without bayes)
mass-check run 1 is for the non-bayes sets. A single --net mass-check
is sufficient since you can just strip out the network results and
generate both of the no-net sets (sets 0 and 1).
>> 05/26: generate scores, etc.
>>
>> 05/31: announce mass-check run 2 (sets 2 and 3), run until 06/11.
>
> Again: sets 1 and 3 (net with and without bayes)
mass-check run 2 is for with the bayes sets. The first set of scores is
needed to do accurate autolearning for _these_ runs. It *does* require
two separate mass-check commands since different sets of scores are
being used for auto-learning.
Maybe this should be documented since it seems like we end up
rediscussing it every release.
Daniel
--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting
Re: New proposed 3.0.0 release schedule
Posted by Duncan Findlay <du...@debian.org>.
On Tue, Apr 20, 2004 at 11:35:06PM -0400, Theo Van Dinter wrote:
> RELEASE RELATED:
>
> 05/07: warn people that mass-check runs will be starting shortly
>
> 05/17: announce mass-check run 1 (sets 0 and 1), run until 05/24.
> enter R-T-C mode.
Minor nitpick: I think you mean sets 0 and 2 (i.e. no net with and
without bayes)
> 05/26: generate scores, etc.
>
> 05/31: announce mass-check run 2 (sets 2 and 3), run until 06/11.
Again: sets 1 and 3 (net with and without bayes)
> 06/13: generate scores, etc.
I kinda remember needing three mass-checks last time, but I'm not sure
why. I'm pretty sure 1 can be generated from 3 and 0 from 2.
--
Duncan Findlay
Re: New proposed 3.0.0 release schedule
Posted by Theo Van Dinter <fe...@kluge.net>.
On Tue, Apr 20, 2004 at 11:35:06PM -0400, Theo Van Dinter wrote:
> CODE RELATED:
>
> 04/20: DONE - get bugzilla prioritized and either close/punt stuff
> we're not going to get to to 3.1. We will need to get agressive about
> some tickets -- for instance: we can't avoid all FPs, so if they don't
> happen often and if it's not easy to fix, accept it, close the ticket,
> and move on. Get open 3.0 tickets down to around 50.
>
> 04/22: feature freeze -- no more adding enhancements to 3.0 w/out vote
>
> 04/28: do bug squashing event for as many remaining open tickets as
> possible. I assume there'll still be a few major ones open.
>
> 05/12: all tickets should be finished and closed. all testing rules
> should be promoted or removed. do testing to make sure the mass-checks
> will be smooth.
Since there are still tickets open, the rest of the schedule can be
ignored for now since we can't go further until the issues are all solved.
:(
--
Randomly Generated Tagline:
"Anybody interested in entrepreneurship, and/or beer ..." - Prof. Vaz