spamassassin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Loren Wilton" <lwil...@earthlink.net>
Subject Re: PROPOSAL: create "SpamAssassin Rules Project"
Date Wed, 20 Jul 2005 05:28:53 GMT
> > The 'one time' idea was that after each masscheck system checked a given
> > file from the test area, it would somehow know that the file had been
> > checked, and would not re-check it again unless it was revised.  That
way
> > users wouldn't have to remember every day to delete the rules they
submitted
> > yesterday so that the same rules won't get checked over and over again.
> > Admittedly this is an optimization, but it is also a convenience.
>
> yeah -- I'm not sure about the desirability of that.   the idea is more
> that this can be used as a rules development area -- not just an "input
> queue" for mass-checks.

Hum.  I would probably be doing the rules development in the sandbox rather
than testbox area (or not committed to svn, or however that would work).

I suspect that svn has some command akin to 'update' that will tell you
which files are newer than the ones on your system.  I would see the
masscheck systems checking to see which files were updated over their local
copies (in some 'inbox' directory), updating the changed/new files, and
copying them to the actual masscheck directory.

If you wanted to keep testing some specific rule against other rules, you
only need to keep that rule in the current file you commit, rather than
depending on it just being around forever cluttering up masschecks.  Or
commit changes to several files that will (maybe) all get tested together,
if they don't all land at the wrong time (during a masscheck start).

>
> > BTW, we have found that a good part of the mass-check script is to run a
> > lint on each submitted file before testing it, and drop any file with
lint
> > errors rather than letting it fail the whole mass-check.  :-(
>
> hmm.  not sure what to do about that one!
>
> traditionally, if a committer checks in something that breaks, everyone
> gets annoyed and they have to buy a round of drinks ;)

We started with that idea.  Then we discovered that it is *really easy* to
have a rule with a bad s/o and see that a single character change should
improve matters, and make said change.  And not see that the added character
should have been escaped...  :-(

Also, we discovered that not everyone had the same system level, and a lint
that succeeded on the developer's system would not necessarily succeed on
any given masscheck system.  Boom.

I'd suggest something along the RDJ method where rules are checked for new
versions, downloaded into a temp directory and linted, and only if they pass
the lint are they moved to the active directory.  I suspect that can all be
done with svn and a little scripting.


> all these things, in my opinion, are stuff that can be worked out
> down the line.

Surely.  I brought them up though at this point since I see them as
virtually the only reason to have such a setup as is being proposed, and
thus something that should be considered very early in the 'gee, good idea!'
phase.  The only other viable reason (getting good rules into SA) is
something that also doesn't appear to be worked out in any detail at all.
However, I agree that that part can wait until it is shown that this
subproject actually produces useful rules.

        Loren


Mime
View raw message