Justin Mason wrote:
Daryl C. W. O'Shea writes:
Justin Mason wrote:
At a minimum I'd disable the 3.2 updates until we figure out exactly
> what we want to do (actually that's what I intended).
OK, sounds fine.
So, to do so, I'd just create an update that contains an identical
ruleset to the one being released with 3.2.0, using say 533971 as the
update number and then add the appropriate txt record to the zone file:
0.2.3.updates.spamassassin.org. 3600 IN TXT "533971"
On top of that, there were lint failures caused (iirc) by plugin
dependencies being missed; and false positives caused by too-high scores,
when multiple rules had good 'freqs' but were matching the same message
subset. (mkrules already takes care of the former, and running a rescorer
like the GA would have fixed the latter.)
FWIW, the rescoring I've got running now seems to be producing sane
scores. I've been using the generated set1 scores for set3 with no
complaints so far.
In any case I'd rather have automatic updates too, I'm just against
releasing the current auto updates the way they are. I really only
meant to switch the 3.2 updates to 3.3 to stop the current auto-updates
for the stable release (for now) and leave a 3.2 update place holder in
DNS with no real updates (until we get acceptable auto-updates).
I'd prefer to have the auto-promotion, updates generation, etc. to
output rules directly to the 3.2.x updates.
The auto-promotion has some issues:
- auto-demotion needs some dampening (say a three day minimum before
being removed or at least a lower criteria for keeping currently
promoted rules); rules are bouncing in and out of the active.list way
too much; of particular interest are rules bouncing in and out around
the weekly non-net, net, non-net 3 night sequence
Yeah, good point.
- auto-promoted rules need auto-generated scores; there's been a number
of instances of duplicate rules with 'big' scores causing FPs in the
manual updates... and somebody had to manually add those rules and
scores without noticing the problem, doing the same thing
automatically can't be any better
+1. No, I agree -- the auto-generated scores are essential to avoid
the FP situation I mentioned above.
I'm happy with using the generated scores I've got running now. I'm
open to comments, changes, or something different though.
- at some point trunk, which the updates are currently based on, is
probably going to diverge in compatibility from 3.2; that's not an
issue now but down the road there's potential for breakage... any
automated process should try to at least lint the updates with all
targeted versions of SA (this still applies if the updates become
based on stable branch mass checks and not trunk)
I'm not too worried about that... trunk can break ;)
I'm not concerned about breaking trunk, rather, I'm concerned about
using trunk to generate the stable branch updates and breaking the
stable updates. I can't think of anything obvious that the client side
sa-update lint wouldn't catch, but even having the client update detect
the update as being bad is, well, bad.
Regardless of what the updates are based on, really, there should be a
step in the automated process that attempts to lint the update against
every version that the update is targeted for. In the event of a
failure the update won't be published (maybe it already does this, but
I'd don't remember it doing so).
In any case, this one isn't a show stopper, it's something that I can
look at implementing post 3.2.0 release.
Daryl
