Daryl C. W. O'Shea writes: > Justin Mason wrote: > > Daryl C. W. O'Shea writes: > >> Don't forget to change the current trunk/3.2 updates into 3.3 updates > >> and create 3.2 updates similar to 3.1 updates *before* releasing 3.2.0. > > > > do we have to do this beforehand? I was thinking we could get away > > with doing it afterwards. ;) > > 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. > The majority of > the currently promoted rules have no score, scores commented out for the > 3.2 rescoring, or commented scores that are entirely inappropriate. The > updates as currently published are unacceptable IMO. ok. > > by the way -- I'm not in favour of adopting the current 3.1.x updates > > model for 3.2.x, where they have to be manually backported from a dev > > branch by hand -- it's proven fragile (there's been breakages) and is > > pretty much entirely neglected now (there hasn't been an update in 2 1/2 > > months). I think the trunk-style auto-built model works a lot better. > > and what use are updates if they're too hard for us to update? > > Updates for the sake of updates, without ensuring that they're sane > updates, isn't good either. The only breakages I can recall are the > issue with the same update number (fixed by using svn tags) and multiple > rules having the same scores (not any better, possibly worse, with auto > updates). 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.) > 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. > - 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 ;) > > The discussion at > > http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4982 also seems > > relevant... > > Yeah, nothing really solved there. :( > > > Daryl --j.
