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). 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.


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).

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

 - 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

 - 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)


The discussion at
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4982  also seems
relevant...

Yeah, nothing really solved there. :(


Daryl






Reply via email to