-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daryl C. W. O'Shea writes:
> On 09/12/2005 4:48 PM, Theo Van Dinter wrote:
> > On Fri, Dec 09, 2005 at 01:40:03PM -0800, Justin Mason wrote:
> >>I do think it's worth promoting them *somewhere*, btw, instead of leaving
> >>them to moulder in the sandboxes.
> >
> > Sure. I think "promotion" would be to copy the rule into the appropriate
> > two
> > places (core and sa-update) and go from there. I just want to make sure we
> > come up with a reasonable policy/procedure before we move forward.
>
> That sounds like the way to go to me. The rules can sit, waiting for
> sa-update to be ready, in the sandboxes just as well as they can
> anywhere else in the tree.
>
> I don't think anyone's going to nuke good rules in their sandboxes, so
> that shouldn't be a problem.
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.
regarding scoring: I think we may have to hand-guess scores initially.
in other words, let's do this gradually, instead of blocking everything on
sa-update and a rescoring system.
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:
core/
[...released, unupdated rules files]
sandbox/
[...sandboxes]
update/
[...updateable rules files]
then build/mkrules can just be fixed to treat "update" the same as "core".
Or -- better -- shouldn't sa-update be able to update with changes to the
core ruleset anyway?
- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFDmgzOMJF5cimLx9ARAvf9AKCo+qn5Orfk60+pa2DmdEGqo0EZggCeO6pN
2ZxoQRRj3X0bFM0sbXc4tzY=
=erQp
-----END PGP SIGNATURE-----
