3.2.x updates (Re: [VOTE][DRAFT] SpamAssassin 3.2.0)

[Justin Mason <jm...@jmason.org>]

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

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?

I'd prefer to have the auto-promotion, updates generation, etc. to 
output rules directly to the 3.2.x updates.

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

--j.

Re: 3.2.x updates (Re: [VOTE][DRAFT] SpamAssassin 3.2.0)

["Daryl C. W. O'Shea" <sp...@dostech.ca>]

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