-----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:[EMAIL PROTECTED] > Sent: Wed 7/13/2005 11:59 AM > To: Theo Van Dinter > Cc: [email protected] > 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:[EMAIL PROTECTED]<BR><B>Sent:</B> Wed 7/13/2005 11:59 > AM<BR><B>To:</B> Theo > Van Dinter<BR><B>Cc:</B> [email protected]<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-----
