You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2005/07/13 21:34:24 UTC
Re: many score changes from 0 to .0001?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dale Luck writes:
> Could someone fill me in on the reason for these? I suspect its so that we can monitor hits/usefulness without affecting the scores.
yep, for the mass-checks. If you're tracking svn trunk, you
really need to track the dev@ list too ;)
- --j.
> Unfortunately, in a production environment, these rules waste a lot of cpu time and lower the thruput of the system.
>
> I've already modified my conf source code so that I can specify a
> score threshold for zeroing out rules, (also I completely chuck the
> rules if all score columns are zero, an an attempt to elliminate
> bloat).
>
> dale
>
> ________________________________
>
> From: Justin Mason [mailto:jm@jmason.org]
> Sent: Wed 7/13/2005 11:59 AM
> To: Theo Van Dinter
> Cc: dev@SpamAssassin.apache.org
> Subject: Re: VOTE: make t/ C-T-R for minor changes
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Theo Van Dinter writes:
> > On Wed, Jul 13, 2005 at 11:09:40AM -0700, Justin Mason wrote:
> > > "masses" is currently under C-T-R for minor changes. I propose that
> > > we do the same for "t", too, since bug 4480 is an example of a trivial
> > > t change that fixes a release-breaking bug, and I'm sure there'll
> > > be more.
> >
> > masses is fine with me, since users won't actually be impacted by any changes
> > there. t is a little different, though not as critical as the rest of the
> > code/rules/etc.
> >
> > Basically what I'm thinking is that small changes are fine, but large/complex
> > changes are not. We really ought to be doing "make test" and such before
> > tagging a release and such, btw, so we don't have "release-breaking" t bugs.
>
> FWIW, I did ;)
>
> The problem is that "meta.t" has some unusual dependencies on
> parse-rules-for-masses (which it really shouldn't have), which means that
> it may be silently skipped, or run, depending on platform, and whether
> Storable is installed or not. So whereas it passed on my dev machine, it
> failed on one of the buildbots. messy.
>
> - --j.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Exmh CVS
>
> iD8DBQFC1WSmMJF5cimLx9ARAliEAJ41E4S11wyORkpaQJnmG7c68segLACgj9xJ
> ERiIQeoraXVfvT++SxC4xNQ=aRL+
> -----END PGP SIGNATURE-----
>
> ------_=_NextPart_001_01C587E2.4C987039
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
>
> <META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7232.36">
> <TITLE>Re: VOTE: make t/ C-T-R for minor changes </TITLE>
> </HEAD>
> <BODY>
> <DIV id=idOWAReplyText95993 dir=ltr>
> <DIV dir=ltr><FONT face=Arial color=#000000 size=2>Could someone fill me in on
> the reason for these? I suspect its so that we can monitor hits/usefulness
> without affecting the scores.</FONT></DIV>
> <DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
> <DIV dir=ltr><FONT face=Arial size=2>Unfortunately, in a production environment,
> these rules waste a lot of cpu time and lower the thruput of the
> system.</FONT></DIV>
> <DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
> <DIV dir=ltr><FONT face=Arial size=2>I've already modified my conf source code
> so that I can specify a score threshold for zeroing out rules, (also I
> completely chuck the rules if all score columns are zero, an an attempt to
> elliminate bloat).</FONT></DIV>
> <DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
> <DIV dir=ltr><FONT face=Arial size=2>dale</FONT></DIV></DIV>
> <DIV dir=ltr><BR>
> <HR tabIndex=-1>
> <FONT face=Tahoma size=2><B>From:</B> Justin Mason
> [mailto:jm@jmason.org]<BR><B>Sent:</B> Wed 7/13/2005 11:59 AM<BR><B>To:</B> Theo
> Van Dinter<BR><B>Cc:</B> dev@SpamAssassin.apache.org<BR><B>Subject:</B> Re:
> VOTE: make t/ C-T-R for minor changes <BR></FONT><BR></DIV>
> <DIV>
> <P><FONT size=2>-----BEGIN PGP SIGNED MESSAGE-----<BR>Hash: SHA1<BR><BR><BR>Theo
> Van Dinter writes:<BR>> On Wed, Jul 13, 2005 at 11:09:40AM -0700, Justin
> Mason wrote:<BR>> > "masses" is currently under C-T-R for minor
> changes. I propose that<BR>> > we do the same for "t", too, since
> bug 4480 is an example of a trivial<BR>> > t change that fixes a
> release-breaking bug, and I'm sure there'll<BR>> > be
> more.<BR>><BR>> masses is fine with me, since users won't actually be
> impacted by any changes<BR>> there. t is a little different, though not
> as critical as the rest of the<BR>> code/rules/etc.<BR>><BR>> Basically
> what I'm thinking is that small changes are fine, but large/complex<BR>>
> changes are not. We really ought to be doing "make test" and such
> before<BR>> tagging a release and such, btw, so we don't have
> "release-breaking" t bugs.<BR><BR>FWIW, I did ;)<BR><BR>The problem is that
> "meta.t" has some unusual dependencies on<BR>parse-rules-for-masses (which it
> really shouldn't have), which means that<BR>it may be silently skipped, or run,
> depending on platform, and whether<BR>Storable is installed or not.
> So whereas it passed on my dev machine, it<BR>failed on one of the
> buildbots. messy.<BR><BR>- --j.<BR>-----BEGIN PGP
> SIGNATURE-----<BR>Version: GnuPG v1.2.5 (GNU/Linux)<BR>Comment: Exmh
> CVS<BR><BR>iD8DBQFC1WSmMJF5cimLx9ARAliEAJ41E4S11wyORkpaQJnmG7c68segLACgj9xJ<BR>ERiIQeoraXVfvT++SxC4xNQ=<BR>=aRL+<BR>-----END
> PGP SIGNATURE-----<BR><BR></FONT></P></DIV>
>
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C587E2.4C987039--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFC1WzAMJF5cimLx9ARAqXoAJwOGearXzC0RNoziymlGrt/x4pgvgCePQfx
lGorohmIDWGs4cj/FrxAgR4=
=mUJM
-----END PGP SIGNATURE-----