Justin Mason wrote:
Theo Van Dinter writes:
On Wed, Jan 03, 2007 at 02:42:44PM +0000, Justin Mason wrote:
First step, I think, is to define a schedule. How does this sound?
(based approximately on what we did for 3.1.0:
http://wiki.apache.org/spamassassin/Release310Schedule )
- T + 0 days: announce a heads-up mail. clean up our corpora, get ready
for mass-checking, try out mass-check to spot any big memory leaks or
whatnot, fix remaining bugs that affect mass-checks (esp bug 5260!),
get people signed up, enable all rules in svn.
Ok.
- T + 1 week, around a Thursday or so: start --bayes --net mass-checks;
move to C-T-R.
Did we really whittle it down to a single mass-check? I could have sworn
there were still at least 2 required.
I know, I thought so too -- but looking back through 3.1.0 history,
I can find only one. given the --learn thing, it seems fine.
There was only one required. It may have seemed like more since we had
to restart the process twice after finding bugs.
IMO, I'd hold off on CTR as long as possible. Being a major release, I'd like
to give as much time in pre-release/CTR state as possible.
OK, fine with that.
- T + 3 weeks, a Monday or so: hopefully finish mass-checks, bugs
allowing ;) (note that includes two weekends.)
- T + 3 weeks: perceptron runs, voting on new proposed scores, etc
- T + 4 weeks and a bit: hopefully ready to release
There's no testing time in here. Around T+0 I'd recommend doing a pre-release
cycle, we can work through that while doing the mass-checks. So far there are
probably only enough people running 3.2 that I could count them on one hand,
so a wider test would be good.
ok, prerelease at T + 0 makes sense -- agreed.
Yeah, that's actually what I thought was happening when I read it.
Reading it again I see that I just assumed that a pre release would be cut.
After the scores are set, we should do a final RC set of releases just to make
sure, then the full release after that.
ok. so something like this?
- T + 0 days: issue prerelease. announce a heads-up mail. clean up our
corpora, get ready for mass-checking, try out mass-check to spot any
big memory leaks or whatnot, fix remaining bugs that affect
mass-checks (esp bug 5260!), get people signed up, enable all rules in
svn.
- T + 1 week, around a Thursday or so: start --bayes --net mass-checks.
Please give a heads up before announcing the start of the mass-checks
just in case someone thinks of something at the last minute that should
be done before mass-checks start.
- T + 3 weeks, a Monday or so: hopefully finish mass-checks, bugs
allowing ;) (note that includes two weekends.)
- T + 3 weeks: perceptron runs, voting on new proposed scores, etc.
how's about C-T-R once the new scores are applied? then final
RC set of releases...
- T + N weeks: once we are happy with an RC (so N could be any number
> 3), redo that RC as a full release.
As long as N is an integer and not something like 3.3. At least a week
of availability of the final RC before release would probably be good.
With the above notes in mind... +1.
Daryl
