Differences between revisions 2 and 7 (spanning 5 versions)
Revision 2 as of 2006-01-31 19:46:36
Size: 4070
Editor: JustinMason
Comment:
Revision 7 as of 2009-09-20 23:16:34
Size: 3930
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * A rule starts off in a developer's sandbox. It may be an experimental rule ("tflags nopublish" or "T_" prefix on the name).
 * Alternatively, it may be a non-experimental, but still in-sandbox, testing rule.
 * A rule starts off in a developer's sandbox as an experimental rule, one that he doesn't want to publish just yet.
 * Alternatively, it may be a non-experimental, but still in-sandbox, testing rule.  These need to be marked by the developer with "tflags publish".
Line 10: Line 10:
 * A good rule may be manually copied from the sandbox to the "rulesrc/core" directory.  * A good rule may be manually copied from the sandbox to the "rules" directory.
Line 17: Line 17:
 * '''experimental''' -- don't promote me. "T_" prefix / "tflags nopublish" implies this. These rules are compiled, by the "build/mkrules" compiler at "make" time, to "rules/70_sandbox.cf".  * '''experimental''' -- don't promote me. "T_" prefix in the rulesrc source file, "tflags nopublish", or the absence of a "tflags publish", implies this. These rules are compiled, by the "build/mkrules" compiler at "make" time, to "rules/70_sandbox.cf".
Line 19: Line 19:
 * '''s_poor''' -- promotable, but not meeting promotion criteria. Compiled to "rules/70_sandbox.cf".  * '''s_poor''' -- promotable, listed with "tflags publish", but not meeting promotion criteria. Compiled to "rules/70_sandbox.cf".  "T_" is prefixed to the rule name.
Line 21: Line 21:
 * '''s_good''' -- promotable, and meeting criteria. Rules in this state are copied into the "active set". Compiled to "rules/72_active.cf".  * '''s_good''' -- promotable, listed with "tflags publish", and meeting criteria. Rules in this state are copied into the "active set". Compiled to "rules/72_active.cf".
Line 23: Line 23:
''Rules in core:'' ''Rules in the engine tarball:''
Line 25: Line 25:
 * '''c_poor''' -- promotable, but not meeting promotion criteria. Compiled to "rules/70_inactive.cf".

 * '''c_good''' -- promotable, and meeting criteria. Rules in this state are copied into the "active set". Compiled to "rules/72_active.cf".
 * '''core''' -- no promotion criteria are needed; this is part of the core ruleset. Often tied closely to the distributed {{{Mail::SpamAssassin}}} perl modules. These are not compiled at all by "build/mkrules", and are always distributed. (new as of bug 5123.)
Line 31: Line 29:
 * '''gone''' -- rule has been deleted. If a rule is in c_poor for "an extended period of time", it goes here. (Right now, this has to be done manually.)  * '''gone''' -- rule has been deleted. If a rule scores badly in core for "an extended period of time", it goes here. (Right now, this has to be done manually.)
Line 33: Line 31:
''Legacy:''

 * '''code_tied''' -- rule is very dependent on the distributed {{{Mail::SpamAssassin}}} perl modules, and is therefore still distributed as part of the "rules" directory in the code package. These are not compiled at all by "build/mkrules", and are always distributed.

(History: [http://www.nabble.com/hackathon-notes-from-Sat-p1887702.html mailing list message])
(History: [[http://www.nabble.com/hackathon-notes-from-Sat-p1887702.html|mailing list message]], bug 5123)
Line 43: Line 37:
 * experimental <---> s_poor
 * experimental <---> s_good
 * s_poor <---> s_good
 * c_poor <---> c_good
 * c_poor ->
gone
 * '''experimental''' <---> '''s_poor'''
 * '''experimental''' <---> '''s_good'''
 * (hand copy) '''s_good''' <---> '''core'''
 * (hand copy) '''core''' <---> '''gone'''
Line 55: Line 48:
 * builddir: "./spamassassin", or similar, run from inside build dir
 * make_test: "make test"
 *
mass_check: MassCheck run from inside "masses" dir
 * bbtest: the testing buildbot
 * bbmass: the bbmass buildbot
 * nightly: the NightlyMassCheck
 * make_install: what's installed via "make install"
 * tarball: what's put in distributed tarballs
 *
sa_update: what's delivered via sa-update
 * '''builddir''': "./spamassassin", or similar, run from inside build dir
 * '''make_test''': "make test"
 * '''
mass_check''': MassCheck run from inside "masses" dir
 * '''bbtest''': the testing buildbot
 * '''bbmass''': the bbmass buildbot
 * '''nightly''': the NightlyMassCheck
 * '''make_install''': what's installed via "make install"
 * '''tarball''': what's put in distributed tarballs (by make dist, make disttest)
 * '''
sa_update''': what's delivered via sa-update
Line 70: Line 63:
|| ||'''experimental'''||'''s_poor'''||'''s_good'''||'''c_poor'''||'''c_good'''||'''code_tied'''||
|| '''builddir''' ||    {OK} || {OK} || {OK} || {OK} || {OK} || {OK} ||
|| '''make_test''' ||    {OK} || {OK} || {OK} || {OK} || {OK} || {OK} ||
|| '''mass_check''' ||    {OK} || {OK} || {OK} || {OK} || {OK} || {OK} ||
|| '''bbtest''' ||    {OK} || {OK} || {OK} || {OK} || {OK} || {OK} ||
|| '''bbmass''' ||    {OK} || {OK} || {OK} || {OK} || {OK} || {OK} ||
|| '''nightly''' ||    {OK} || {OK} || {OK} || {OK} || {OK} || {OK} ||
|| '''make_install'''|| || || {OK} || || {OK} || {OK} ||
|| '''tarball''' || || || {OK} || || {OK} || {OK} ||
|| '''sa_update''' || || || {OK} || || {OK} || {OK} ||
|| ||'''experimental'''||'''s_poor'''||'''s_good'''||'''core'''||
|| '''builddir''' || {OK} || {OK} || {OK} || {OK} ||
|| '''make_test''' || {OK} || {OK} || {OK} || {OK} ||
|| '''mass_check''' || {OK} || {OK} || {OK} || {OK} ||
|| '''bbtest''' || {OK} || {OK} || {OK} || {OK} ||
|| '''bbmass''' || {OK} || {OK} || {OK} || {OK} ||
|| '''nightly''' || {OK} || {OK} || {OK} || {OK} ||
|| '''make_install'''|| ||    || {OK} || {OK} ||
|| '''tarball''' || ||    || {OK} || {OK} ||
|| '''sa_update''' || ||    || {OK} || {OK} ||

Rule Life Cycle

The life-cycle of a rule goes like this.

  • A rule starts off in a developer's sandbox as an experimental rule, one that he doesn't want to publish just yet.
  • Alternatively, it may be a non-experimental, but still in-sandbox, testing rule. These need to be marked by the developer with "tflags publish".
  • The developer may decide to switch the rule back and forth between those two states.
  • Non-experimental rules' promotability is measured (see SaUpdateBackend).

  • If it's good enough, it's published to the "active set".
  • A good rule may be manually copied from the sandbox to the "rules" directory.
  • Eventually, it stops being good enough, through the normal attrition process for antispam rules, and it stops meeting the promotion criteria.

List Of Rule States

Rules in sandbox:

  • experimental -- don't promote me. "T_" prefix in the rulesrc source file, "tflags nopublish", or the absence of a "tflags publish", implies this. These rules are compiled, by the "build/mkrules" compiler at "make" time, to "rules/70_sandbox.cf".

  • s_poor -- promotable, listed with "tflags publish", but not meeting promotion criteria. Compiled to "rules/70_sandbox.cf". "T_" is prefixed to the rule name.

  • s_good -- promotable, listed with "tflags publish", and meeting criteria. Rules in this state are copied into the "active set". Compiled to "rules/72_active.cf".

Rules in the engine tarball:

  • core -- no promotion criteria are needed; this is part of the core ruleset. Often tied closely to the distributed Mail::SpamAssassin perl modules. These are not compiled at all by "build/mkrules", and are always distributed. (new as of bug 5123.)

Deleted rules:

  • gone -- rule has been deleted. If a rule scores badly in core for "an extended period of time", it goes here. (Right now, this has to be done manually.)

(History: mailing list message, bug 5123)

State Transitions

The permitted transitions for those rule states, therefore, are as follows:

  • experimental <---> s_poor

  • experimental <---> s_good

  • (hand copy) s_good <---> core

  • (hand copy) core <---> gone

List Of Build States

Some rules are only used from certain build states. Here are the list of states that SpamAssassin goes through, or that rules are packaged as, during various parts of its build process.

  • builddir: "./spamassassin", or similar, run from inside build dir

  • make_test: "make test"

  • mass_check: MassCheck run from inside "masses" dir

  • bbtest: the testing buildbot

  • bbmass: the bbmass buildbot

  • nightly: the NightlyMassCheck

  • make_install: what's installed via "make install"

  • tarball: what's put in distributed tarballs (by make dist, make disttest)

  • sa_update: what's delivered via sa-update

Build States vs. Rule States Matrix

And here's the table listing what rules are usable, where. {OK} indicates that a rule in that state is indeed usable from the listed build state.

experimental

s_poor

s_good

core

builddir

{OK}

{OK}

{OK}

{OK}

make_test

{OK}

{OK}

{OK}

{OK}

mass_check

{OK}

{OK}

{OK}

{OK}

bbtest

{OK}

{OK}

{OK}

{OK}

bbmass

{OK}

{OK}

{OK}

{OK}

nightly

{OK}

{OK}

{OK}

{OK}

make_install

{OK}

{OK}

tarball

{OK}

{OK}

sa_update

{OK}

{OK}

RuleLifeCycle (last edited 2009-09-20 23:16:34 by localhost)