On Thu, Sep 07, 2006 at 03:17:40PM +0100, Justin Mason wrote: > OK -- agreed. However, my point is that we'd be better off doing that > work as part of the 3.2.0 development, and later for 3.3.0 -- rather > than trying to "retrofit" it into 3.1.6 or 3.1.7, I think. > > There's no *need* to keep 3.1.x going, if we can start getting 3.2.0 > released instead.
Sure. My point was that as far as I can tell, it's the same amount
of work to get it working for 3.[123] as it is for 3.[23], so why not
do that?
> Hmm -- I think I'd need more details of how that'd work -- I'm not
> sure I get it.
Ok. Keep 3.1 the way it currently is, semi-revert 3.2 to have a rules
directory and we'll put a minimal set of 3.2 rules in there.
External to the normal distro, we have code that generates updates based on
the mass-check results (or whatever else we want to base them on).
> One thing I'd want to avoid is having to set up two separate SVN
> workspaces to get a usable checkout, or having to download two separate
> tarballs to get a usable release. In my opinion, the core code
> is nearly useless without rules, so there isn't a need to ship it
> without them.
What do you mean by "usable checkout" ? If you mean you want to do one
checkout to get the engine and all the rules, we can discuss how to do that.
I think the engine with a short amount of core rules (which we could update
manually from the rulesrc area) would work perfectly well.
The original idea to split off the rules stuff into a subproject was to more
concretely separate the two areas that we work on, which we've been working
towards for a while now. At the moment, the rules stuff is being forced to
integrate with the engine in roughly the same way it did before, which doesn't
make a lot of sense to me.
At ACUS last year, the idea we discussed (and I thought agreed on) was
to split the two areas and use sa-update to deliver all the rules --
during which time I clearly remember at least mentioning the idea that:
- user downloads the engine, installs it
- user runs sa-update, gets the rules
- user starts using SA, keeps running sa-update periodically to get new rules
The idea there was to specifically have no rules distributed with the engine,
and people would have to use sa-update (or download an update manually) to
get the rules. I think our current methodology of:
- user downloads the engine, installs it, it comes with a core set of rules
- user is encouraged to run sa-update, and then run it periodically as well to
get the complete set of rules
works well. It doesn't require us to have everything in the engine
distribution though.
> I was also thinking we should set up some trusted spamtraps to collect
> lots of spam with "live" network test data -- I think most of our spam
> corpora we're mass-checking nowadays is incomplete. for example, my
> corpora will omit everything that hit SBL+XBL, and Michael's is similarly
> omitting lots of those too. Nowadays spamtrapping may be the only viable
> way to get a really representative spam corpus....
FWIW, my personal mail and my spamtraps have no filtering other than SA.
I can create new/share some of my current spamtrap addresses if people
want to "spread them around" more than I have (which isn't a lot).
--
Randomly Generated Tagline:
"I instigated Linus's first shooting expedition in a long while a few months
back (I can report that he is a steady, competent shot with a 9mm semi)."
- Eric Raymond
pgpm36x4ihufq.pgp
Description: PGP signature
