sandbox/sa-update thought

[Justin Mason <jm...@jmason.org>]

We currently have this auto-publishing of rules from sandbox to sa-update,
based on how well they do in some automated testing. The thing about
URIBL_RHS_URIBL_BLACK (which is a test rule) made me think, though --
should we modify this to require a more explicit sign-off for the rules
that we want published?

We can already do this (labouriously) by adding "tflags nopublish" to
every rule, or renaming them to have the T_ prefix.  What I'm thinking
though, is that rules in sandboxes be implicitly considered "nopublish"
for sa-update use, unless *explicitly* marked "publish".

This would be in addition to the automated testing step, too. In other
words, a rule would have to:

    - be in rulesrc/sandbox/whoever/foo.cf
    - not named T_SOMETHING
    - be listed with "tflags publish"
    - pass the QA freqs thresholds

to make it into sa-update.

This was we wouldn't get test rules like URIBL_RHS_URIBL_BLACK (which
seemingly had good enough freqs to be published) getting into updates;
whereas when we write new rules that *are* intended for updates (assuming
they work and catch enough spam), they'll get published easily.

I think that should cut down on the danger of test rules getting
published when we don't want that to happen.

Thoughts?

--j.

Re: sandbox/sa-update thought

["Kevin A. McGrail" <ke...@thoughtworthy.com>]

As discussed prior, I *thought* the sandbox was a playground aka wiki 
sandboxes where it was just lines in the sand washed away by the next tide. 
I was very surprised to find out they auto-promoted.  I would support the 
explicit nature you refer to below.

Regards,
KAM

> We currently have this auto-publishing of rules from sandbox to sa-update,
> based on how well they do in some automated testing. The thing about
> URIBL_RHS_URIBL_BLACK (which is a test rule) made me think, though --
> should we modify this to require a more explicit sign-off for the rules
> that we want published?
>
> We can already do this (labouriously) by adding "tflags nopublish" to
> every rule, or renaming them to have the T_ prefix.  What I'm thinking
> though, is that rules in sandboxes be implicitly considered "nopublish"
> for sa-update use, unless *explicitly* marked "publish".
>
> This would be in addition to the automated testing step, too. In other
> words, a rule would have to:
>
>    - be in rulesrc/sandbox/whoever/foo.cf
>    - not named T_SOMETHING
>    - be listed with "tflags publish"
>    - pass the QA freqs thresholds
>
> to make it into sa-update.
>
> This was we wouldn't get test rules like URIBL_RHS_URIBL_BLACK (which
> seemingly had good enough freqs to be published) getting into updates;
> whereas when we write new rules that *are* intended for updates (assuming
> they work and catch enough spam), they'll get published easily.
>
> I think that should cut down on the danger of test rules getting
> published when we don't want that to happen.
>
> Thoughts?

Re: sandbox/sa-update thought

[Sidney Markowitz <si...@sidney.com>]

> I think that should cut down on the danger of test rules getting
> published when we don't want that to happen.

I agree. I also assumed that the sandbox was set up like that until I
had occasion to run some test rules. Your proposal makes the whole
process take fewer steps as well as being fail-safe -- There's no need
to remember to use special names or flags when you are first creating a
test rule, and just the step of adding one flag when you are ready to
publish.

 -- sidney

Re: sandbox/sa-update thought

["Daryl C. W. O'Shea" <sp...@dostech.ca>]

Justin Mason wrote:

> This would be in addition to the automated testing step, too. In other
> words, a rule would have to:
> 
>     - be in rulesrc/sandbox/whoever/foo.cf
>     - not named T_SOMETHING
>     - be listed with "tflags publish"
>     - pass the QA freqs thresholds
> 
> to make it into sa-update.

+1.  I think we actually discussed doing this before, too.  At least I 
remember sending mail about it.

Daryl