On Fri, Dec 09, 2005 at 03:01:34PM -0800, Justin Mason wrote: > well, to my mind, I'd prefer to have them sit somewhere that means "these > are ready to go, but not yet in a release tarball". There are people > running SVN trunk, for example, and they'd find it useful to get those > rules without digging them out of sandboxes.
I'd suggest either promoting from sandbox to both core and the update dir (that way we don't later have to figure out what to move to core), or promote from sandbox to updates and then when we're ready to do rc/score generation runs for the next major release we take a snapshot of the rules from update and move to core. > regarding scoring: I think we may have to hand-guess scores initially. yeah, ditto. > in other words, let's do this gradually, instead of blocking everything on > sa-update and a rescoring system. Yeah, they're separate issues anyway. I'd just love to get, say, monthly rescoring runs going at some point, which we'd deliver via sa-update. > Theo: copying to two places: I can go for that. I'd prefer just the one, > though ;) Why not get sa-update to read from another dir in rulesrc, > something like: > [...] > Or -- better -- shouldn't sa-update be able to update with changes to the > core ruleset anyway? Hrm. What I expected was to just have a directory which we put the file in, then tar up an svn export and that's the update. I guess it could easily instead be a script that you run, ala mkrules, which generates a directory and tarball, and then you can have the source files wherever appropriate. I'm open to either way. I already made an update/3.1 directory structure (at the .../spamassassin level), but could move it to the rulesrc area. -- Randomly Generated Tagline: !ereh fo tuo em teg ydobemoS .rotinom eht ni m'I !pleH
pgpzfSNqiWBrh.pgp
Description: PGP signature
