After the release of 3.3.0 we need to think about how rule updates as
distributed via sa-update will work. The goal here is to make it quick
and easy to safely add new or adjust existing rules so sa-update keeps
spamassassin effective over time. This extends the useful life-span of
a spamassassin release. We can then propose a 3.3.x maintenance release
only after we feel enough worthwhile changes make it worthwhile to do a
release, or for security releases.
jm explained a few weeks ago that currently 3.2.x sa-update rule updates
are not auto-updated because we lack a separate ruleqa system. Our
ruleqa system tests only the svn trunk in the nightly masscheck. It
would be too much for our nightly masscheck volunteers to run the
nightly masscheck twice, so doing both is not an option.
In talking with jm a few weeks ago, we seem to be in agreement that we
should change this procedure for 3.3.x. Nightly masscheck will continue
to check using the svn trunk, but rule updates will be pushed to 3.3.x
users.
Rule Version Conditionals
=========================
jm says he added a conditional system that might allow us to mark
certain rules as compatible with a certain version of spamassassin.
This will allow us to add new types of rules to trunk without breaking
3.3.x rule updates. Is there any documentation for these rule conditionals?
With rule version conditionals we might consider that svn trunk targets
the next 3.3.x maintenance release instead of working on a branch. We
have limited developer hours so we might be better off focusing
exclusively on trunk. This worked reasonably well during the past year
with pre-3.3.0 trunk. Any thoughts about this part?
Explicit Promotion
==================
The ruleqa system periodically has problems where it gets stuck having
processed only the bb-* corpora but not others. This seems to cause the
combined results to swing wildly and rules are promoted and demoted for
seemingly no reason.
The ruleqa system is incapable of auto-promoting rare hitting but
ultra-accurate rules like VANITY.
For reasons like this, we should force active certain rules when we're
certain they are safe. Adding the rule to rulesrc/10_force_active.cf
seems to be sufficient.
I propose that we have simple, low bar of requirements to govern
explicit promotion.
* By judgement call the rule is obviously safe, or proven by ruleqa.
* Any two commiters agree.
* No bug required, but state who agreed in the commit.
Scoring
=======
Currently auto-promoted rules all have the score of 1. Scores need to
be defined in rules/50_scores.cf to have any other score.
I propose that we have simple, low bar of requirements to control
assignment of any score greater than 1.
* One committer per point must agree, rounded up. (1.4 points require
two committers to agree. 2.3 points require three.)
* No bug required, but state who agreed in the commit.
Comments?
Warren Togami
[email protected]
