"Loren Wilton" writes: >> let me know what you all think. > >I had a little trouble following this message. Part of the problem is I'm >not positive I know what you mean by "compiled rules". (Or I'm positive I >don't know, your choice. :-)
OK, so here's what I've done so far. Rules files are now "compiled". This allows us to - put possibly-broken rules-in-development in the "rulesrc" source directory, without causing damage to the main ruleset if they are broken - split rules across multiple directories, to allow the "sandbox" idea - keep rule source in the same place, even as the rule is promoted, demoted, etc. In actual fact, "compilation" is really just a script that copies the lines from the source file into a destination file in the "rules" output directory, so it's pretty simple. >I also have a question on the "code tied" rules. Which part of these rules >are these? You mention evals. I would assume that the actual eval code for >release N.M is still in the SA code base, so these would just be the the >rules that call the eval functions? Yep, that's the basic issue. http://wiki.apache.org/spamassassin/RulesProjPromotion lists the rulesets that were split, and to where -- pretty much all the current set of eval rules are "code-tied" and have to stay with the code. >It seems to me there is the interesting point that some of these rules might >be common across a few releases and others might be specific to a release. >I'm not quite sure how you handle that case. Maybe rules/evals/3.0, >rules/evals/3.10, etc? we can't really do that, since they might change *between* releases as well -- and if we went down that route, we'd have so many rules/evals/3.0_20050918 etc. directories that we'd eventually wind up reinventing SVN ;) The easier option is to keep those "code-tied" rules as part of the source distribution. >It definitely seems to me that you don't want the test rules to be landing >in the same directory with existing rules. But I didn't follow quite well >enough to suggest something, other than I'd rather use more directories and >keep the CF suffix. I actually don't mind the test rules landing in the same dir as the compiled existing rules, but just not in the same dir as the *source* for the existing rules. Thanks for the vote on the "use more directories" idea though ;) --j.
