https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6510

--- Comment #6 from Daryl C. W. O'Shea <[email protected]> 2010-11-06 
17:38:49 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #1)
> > > +  sed -e 's/0\.000/0.001/g' < trunk-rulesrc-scores/72_scores.cf >
> > > trunk/rules/72_scores.cf
> > 
> > Yeah, that won't work well.  It'll enable net rules in non-net scoresets.
> Would that cause problems given the presence of "tflags net" on net rules?
> Surely SA does not rely on the score being zero to disable net rules when run
> in local mode...

Good point, investigating now.

> > I think I'll change the script to abort the update if lint detects 
> > dependency
> > issues.  I missed tonight's update (I think there's yet another rule or more
> > that will have zeroing issues)... so I'll look at it tomorrow.
> That would keep the update from breaking things at the cost of possibly
> blocking rule and score updates for extended periods while the rescorer is
> misbehaving.

Yeah.  I'm not sure what's better.  No update or people complaining about the
update.

> If we can put a check into the rescorer that does not allow scores to go to
> zero on published rules (taking into account net vs. non-net as my hack does
> not, if that's indeed critical) then that should be done. As I said earlier, 
> if
> a rule is performing well enough to be published then it should not be 
> assigned
> a zero score.

Perhaps we could use the non-mutable flag to stop the GA from doing this. 
Really, though, in promoting the rules we don't look at whether there's any
point in having the rule (super-redundant, or whatever).

> Any idea why the scores are jumping around so much? That bothers me too, 
> though
> it's not as problematic as scores going to zero for no discernible reason.

I'm not sure they're really changing that much.  A few tenths here and there
and the occasional large jumps are to be expected due to the nature of the GA.

-- 
Configure bugmail: 
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to