---
I guess that part of making the rule submission and test process nimble is
for the submitted rules to be independent of anything else. That makes
changing metarules less of a nimble process. That's fine, because metarules
are really just an optimization which can be implemented after the fact when
you see that rules you want to adopt can best be processed that way.
---
Not really. Well, using metas for optimizations is indeed one use, and
there are some rulesets that have found that convenient.
The main use for metas though is to express things that you can't do in a
single regex, such as checking for a specific subject term and a given mime
boundary format. Its likely that a rule will already exist for the mime
boundary that will be used in the final meta, and only the subject test will
be new, as well as the meta combination being new.
You can run such a test by relying on the mime boundary test being in the
rules, or you can pull it into your own test file as a T__ rule. With
something like that it could be done either way, probably with impunity.
One of the basics of our one-off masschecks is that the standard release
rules are expected to be there. However, the sare rules are generally not
expected to be there. So you can build on standard rules, but need to pull
in any standard sare rules.
Now, how should the SA one off masschecks work... Possibly they might not
even have all of the standard rules. We don't have the sare rules in the
one-off checks (usually) since they are things that we are likely to be
mucking with, and having the existing rules there will only create
confusion. In the SA rules case, there is a fair chance that the standard
rules might be getting mucked with.
I suspect it would work either way, and is something that can be
experimented with to find what works best.
Loren
