-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Loren Wilton writes: >Looks generally good. Minor comments: > >1. Bob had a thing built into his version of mass-check that assigns default >scores. I'm not clear on the basis for this (although he has explained it >any number of times) but it is fairly simple and seems todo a decent job, >shy of a full scoring run. > >I'm sure Bob will be happy to explain the method he uses for default score >assignment. Note that the default score isn't always assigned - sometimes a >manual score assignment is done when that seems like a better idea for >whatever reason. Yeah, it may be worthwhile using something like this. Alternatively we may be able to do full perceptron runs... >2. Pass lint: Easy enough to accomplish in a few tries when the rule is in >your personal sandbox. You can get all the necessary dependencies present >and have it work. When promoting manually to the real rules, there is both >the chance of a copy/paste error, and the chance of missing or changed >dependencies. The good news here is that "make" will now immediately flag lint-failing rules. I think this will help a lot. >Suggestion: the promotion movement be in some way automated. The promoter >of the rule enters the rule name(s) into a tool for promotion. Possibly >also the file name can be suggested, otherwise all of the user's sandbox >files that could contain a tested rule are examined to find the rule. > >The rule would be located and moved into the 'released rules' files. >Possibly the promoter could supply a uggested target file name. Any >dependencies would be detected and also moved, unless they duplicated rules >already existing in the base rules. Any rule duplicating the name of a base >rule, but not the function, would cause an error, and the rule and >dependencies woudl NOT be moved. > >Possibly also the source file would get renamed to xxx_released.cf (or moved >into sandbox/released_rules/xxx.cf) if there was no non-released rule in the >file, or perhaps removed from the current file and a new file created >containing the released rule and psooibly the dependencies. > >I kinda envision this being done with a web form type thing where the rule >creator can enter a rule name, select an optout file name from a pulldown >(optionally entering a new file name), check a checkbox fo moving the rule >to the released_rules subdirectory, and another checkbox for moving/deleting >the dependencies. Obviously there are other ways to accomplish similar >results. This was similar to the original idea -- but it's proved pretty complex, and so far has proved very tricky to script. It's proving a *lot* easier to just cut and paste the lines by hand, as before, and I don't think we're losing anything that way. - --j. >----- Original Message ----- >From: "Justin Mason" <[EMAIL PROTECTED]> >To: <[email protected]> >Sent: Friday, November 11, 2005 6:34 PM >Subject: rule promotion criteria > > >> hey all -- >> >> The next feature needed for the rule-QA app is a visible display of >> whether or not a rule hits the promotion criteria (see wiki). We haven't >> yet fully defined this, but now's a good time! >> >> Could you all take a look at >> http://wiki.apache.org/spamassassin/RulesProjPromotion and followup with >> your comments? >> >> --j. > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Exmh CVS iD8DBQFDeTExMJF5cimLx9ARAoQnAJ4hVOZ4v4kLbVasS3LnzRrPyojJyACgpFaL mlhhIfgo/ULBj+5SDSeDezY= =6Wlm -----END PGP SIGNATURE-----
