https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6155
AXB <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #167 from AXB <[email protected]> 2009-11-17 07:56:17 UTC --- (In reply to comment #166) > (In reply to comment #164) > > > It appears that tests here are failing after commit because rules > > > required by > > > this test were zeroed out. It seems these rules have almost zero hits in > > > masscheck. What should we do about this? > > > > Bug 6155 #163: force nonzero scores on MISSING_HB_SEP and X_MESSAGE_INFO > > for the test > > Sending t/missing_hb_separator.t > > Committed revision 881240. > > > > I hope this is the right approach. Alternative would be to introduce > > a file similar to t/data/01_test_rules.cf to hold score overrides, but > > with a name like 51_test_rules.cf to be sorted after the 50_scores.cf. > > Btw, is the 01_ in the name intentional, or could the existing file > > just be renamed to something like 99_test_rules.cf ? > > X_MESSAGE_INFO can be dropped, but MISSING_HB_SEP should not have been made > mutable; I'd say lock to 2.5. > > btw it is to be expected that with less mutability the scores become slightly > less optimal for the rescoring corpus; this always happens. If scores are > allowed to wander without locking down the "unsafe" rules, the GA will overfit > to the training data and produce great FP/FN figures, but scores that are > risky > for "real world" usage. locally, I've have lowered the MISSING_HB_SEP score to 0.5 lottsa funky ERP stuff seems to have a talent to FP on it. its great for metas but usually triggers scores close to FP with the usual suspects & their very ugly HTML formatting. (sorry, cannot supply samples) I'd say 2.5 is sorta high Axb -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
