Re: time to make 3.0 happen

[Justin Mason <jm...@jmason.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Theo Van Dinter writes:
> > 3. I propose we enter Review-then-Commit mode for HEAD on Monday morning
> >    at 0900 UTC.  That should be enough time to cycle everything out of
> >    70_testing.cf, including some network tests that I need to add (NJABL
> >    has a new dynamic list I want us to test) before this weekend.
> 
> I'd rather not.  We have a release plan already, I'd rather stick to
> it and update the dates.  In short, it says we should get everything
> done, get votes for enhancements before moving to the 3.0 queue, and
> get the mass-checks started.  RTC mode is good for the start/end of the
> mass-check runs.

I suggest we don't need RTC just yet, but RTC should definitely be the
case as soon as the mass-checks start, at least, and remain in place until
release. But we will need speedy reviewing, note!  otherwise it'll slow us
down too much.


> > 5. We release 3.0.0-pre1 in one week to have more people start testing
> >    it.  It already has better accuracy for both FPs and FNs than 2.63.
> 
> We could put in general scores based on the daily/weekly runs for pre1,
> btw.  Just a thought.

yeah, either way -- I'm happy with releasing a pre1 with whatever.  I
would *prefer* tweaked scores, as I've received one or two FPs.  but
generally it's been rock-solid for me, and much better than 2.6x.

> Currently open tickets and my comments:
> 
> 2427	enh	Add combined rules file to improve scores on multiple rules
> 3431	enh	[review] feature to add hostname of the remote client to ...
> 2853	enh	[review] Rewrite masses/ (in perl)
> 3435	enh	Support for --long-options for spamc?
> 1645	enh	updated french ruleset
> 
> I think all of these can be punted.  2427: needs testing.  3431 is pretty
> much done I think so that should be trivial to get in and close.  2853:
> good idea, but I think it's too complex for right now.  3435: I thought
> this was going to be easily straightforward, but it's clearly not, doh.
> 1645: french rules?  needs french mails/results/etc.  too complex for now.
> except for 3431, 3.1.0?

yep, +1 on that.

> 3082	nor	auto-whitelist database needs expiry
> this is really an enhancement, and isn't complete enough for 3.0 imho.  3.1.0.
> 2037	nor	SQL efficiency: keep persistent DB connections
> also an enhancement, and has no code or anything.  3.1.0.

see Michael's mails.

> 3169	nor	Fix SPF failures
> I think this is done?

I think so too.  All that's left is actually figuring out some usable
rules from the SPF results!

> 2987	nor	Put user config options at top of Conf.pm
> we're already on the way for this, so may as well finish it.

yep, done...  feel free to do any further moving around of options
you all feel like doing, BTW.

> 3438	nor	Conflicting API documentation
> whatever, doco fix, just do it.

yep.

> 3326	nor	Bayes db update ignored: Too many open files
> as far as I can tell, this isn't an SA issue.  so far, it's been DB_File,
> ulimit, and the crazy HTML-taint issue which we all agree shouldn't ever
> have been possible.  I'd be fine closing this out now as WFM.

yep. +1

> 3059	nor	runaway spamd with pyzor (uses 100% CPU and does not return)
> JM can't reproduce, no response from the submitter for a while.

done

> 3414	maj	BayesSQLStore schema for PostgreSQL wrong
> 3415	maj	BayesStoreSQL quoting issues with PostgreSQL
> 3378	nor	Bayes SQL: fix possible slow query in nspam_nham_change
> 3380	nor	Bayes SQL: Clearing an empty database burns a user id nee...
> 3381	nor	Bayes: Restoring a backup file with spam_count == 0 and/o...
> 
> these need to get done.   3378, at least, has a patch already.
> 
> 3295	maj	FORGED_DEF_WHITELIST false positives for Yahoo and Orbitz
> 
> 3.0.1?

yeah, not really bothered either way here.

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFAt+W0QTcbUG5Y7woRAoZEAKDKCxNf9x/Il6Jg9LpMdgT3jCwAtgCgpDQb
vVuois8n7vFaSTJWa1CS2aA=
=ZurB
-----END PGP SIGNATURE-----

Re: time to make 3.0 happen

[Daniel Quinlan <qu...@pathname.com>]

jm@jmason.org (Justin Mason) writes:

> I suggest we don't need RTC just yet, but RTC should definitely be the
> case as soon as the mass-checks start, at least, and remain in place until
> release. But we will need speedy reviewing, note!  otherwise it'll slow us
> down too much.

I think we should start R-T-C mode soon (that is, on Monday).  Four
reasons:

  1. Releasing: I think R-T-C will actually help speed up the release.
     We should focus on getting the release out.  My experience is that
     it has never slowed down development (in general, not just the
     release process) since more people hang around on IRC and AIM to
     review stuff when we're in R-T-C.

  2. Focus: R-T-C will encourage people to focus on critical stuff and
     drop stuff we don't need.  It's also a pain, so everyone is
     motivated to move at a reasonable pace, not add bugs to the queue,
     etc.

  3. Stability: I'd like to only a small number of pre-releases and I
     think some period of R-T-C mode *before* the last one is necessary
     to make that happen and make sure things are stable.  I think
     waiting for the sake of "convenience" is apt to be a mistake.

  4. Going into R-T-C mode is accepted Apache practice.  When we haven't
     done it long enough, we've experienced bad results and brown paper
     bag releases in the past.

So, (how do I put this nicely?)  stop your whining and suck it up!  ;-)

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/