-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Chris Santerre writes: > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Friday, July 29, 2005 6:53 PM > > To: scottn > > Cc: [email protected] > > Subject: Re: PROPOSAL: create "SpamAssassin Rules Project" > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > scottn writes: > > > > ... few rule writers. > > > > This is explicitly what you (we) are trying to change. > > > > > > Is there a HOWTO for prospective rules writers? > > > Examples maybe? > > > > > > If so, it should be more obvious from the spamassassin main > > web page. > > > If not, then IMO documentation about the current process would > > > be more helpful than changing for some other process, no matter > > > how much "better" the new process is. > > > > the current process is like this -- > > > > - - contributor develops rules > > - - opens a bugzilla bug about it > > - - attaches the ruleset, as a file > > - - signs a CLA, if it's a big ruleset > > - - SpamAssassin committers come along, extract the rules, > > and copy them > > into "rules/70_testing.cf"; possibly renaming them along the way! > > - - later -- those rules are mass-checked > > - - later -- the results are available on the web > > - - if results are good: > > - the rules are checked in > > - - if bad: > > - they're not. > > > > The failures are: > > > > - - there's too much human legwork involved. cut out requiring the > > committers to schlep stuff around just to test the rules. > > Auto corpus checks being the first line is the best method. Only after > getting those results back to the rule writter for corrections, should a > complete mass check be done. well, for a contributor who wasn't already "in the loop", they'd still have to go via some other human to get them tested, under the current proposed new system... mind you, I think this is unavoidable, and OK as long as we have enough people with privs anyway. (Reason: I don't think we're yet secure with a system where *anyone's* regexps would run on various "real" computers -- security and DoS issues. "full FOO /.* .* .* .* .*/" could really run slow, and there may be potential code-execution holes in the regexp system.) > > - - there's no defined way to feed back results from testing > > to the original > > contributor, which can result in stuff getting overlooked > > The above is key. Many times a simple regex change can make an OK rule into > a GREAT rule. yeah. > > - - having to rename the rules is a bit of a mess. not sure > > if there is a good way to fix that though > > Do you mean simply categorizing the names, or the rights to rename? no -- the problem is that a rule that comes in as "GREAT_RULE" may come out the other end as "MID_INVALID_BAT_4", and there's no way to track the rule renames from end to end, without following it slowly back through SVN history (which is hard work). naming isn't really much of a big deal but it'd be nice to have some way to keep track of that. (not that I can think of it.) - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFC7shwMJF5cimLx9ARAg+oAJ9u3m5yppyxaQ6GVnsoIg0TM6b1JQCgs0zi TmW6wpDmZoqZteSWsFP4PgI= =vCPu -----END PGP SIGNATURE-----
