http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From [EMAIL PROTECTED] 2007-07-12 10:31 ------- (In reply to comment #17) > Well, frankly, I have 2 solutions to that -- perl/another script as you > mentioned, but more realistically: why doesn't Fred just commit his own > rules, then you can let him do that for himself. :) OK, another example, using rules from a non-committer this time. In fact, this is the issue that started this whole thing off! Bug 4104. In that case I took a ruleset attachment from http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4104#c9 and put the entire thing into svn as rulesrc/sandbox/jm/20_bug4104_uribl.cf . (It was side effects of that that caused this discussion in the first place! ;) One purpose of "build/mkrules" is to try to fix the rules code in the sandbox area, so that it's safe to use with the (more correct, 'safer') distribution ruleset. For example, it renames rules that duplicate the names of existing rules, blocks syntax errors from getting into 72_active.cf, and renames rules marked with "nopublish" to include "T_" as a prefix. That's what it does. This would be just another case where it's fixing up possibly-'unsafe' input during "compilation". Regarding the idea of doing the fix-up with another script prior to checkin, there's a possible problem with that, which is if there are incremental changes to the file. Consider a contributor submits this rule file: header __BAR Bar =~ /bar/ header BAZ Baz =~ /baz/ header GLOOP Baz =~ /gloop/ header FLOOB Baz =~ /floob/ [... another 50 rules in similar vein] meta FOO (RCVD_IN_NJABL_SPAM && !__BAR && BAZ && !GLOOP && [...]) (note the reference to 'RCVD_IN_NJABL_SPAM', a distribution rule.) we run the script and it converts that to: header __BAR Bar =~ /bar/ header T_BAZ Baz =~ /baz/ header T_GLOOP Baz =~ /gloop/ header T_FLOOB Baz =~ /floob/ [... another 50 rules in similar vein] meta T_FOO (RCVD_IN_NJABL_SPAM && !__BAR && T_BAZ && !T_GLOOP && [...]) note that 'RCVD_IN_NJABL_SPAM' has not been changed. We check it in. If the contributor later posts a comment saying "oops! please change these rules: BAZ, FLOOB, and FOO to read: header BAZ Baz =~ /baz/ header FLOOB Baz =~ /floob/ meta FOO (RCVD_IN_NJABL_SPAM && !__BAR && !BAZ && !GLOOP && [...]) we no longer have a copy of the original file; we just have the "compiled" format in SVN. so we now have to hand-convert those new lines to the "compiled" rule names. In other words -- it's a bit like checking in compiled output, instead of the source code, to my mind. (I guess this kind of incremental updating is annoying and will always require hand-merging anyway, though, so this isn't a major objection.) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
