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 2007/05/03 11:45:19 UTC
Re: svn commit: r534718 - /spamassassin/rules/trunk/sandbox/sidney/70_other.cf
sidney@apache.org writes:
> Author: sidney
> Date: Wed May 2 22:45:09 2007
> New Revision: 534718
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=534718
> Log:
> metas cannot reference metas. fix that and use complete set for tests
actually, that should be fine... metas can depend on metas.
--j.
Re: svn commit: r534718 - /spamassassin/rules/trunk/sandbox/sidney/70_other.cf
Posted by Sidney Markowitz <si...@sidney.com>.
Daryl C. W. O'Shea wrote, On 4/5/07 9:01 AM:
> The rules aren't in the mass-check logs for r534356 (at least not in the
> copy I have from 23:00 UTC yesterday), rather something with the ruleqa
> app is apparently screwed up.
It all looks more reasonable now, with 20070503-r534754-n being the
current nightly mass check. Maybe there is some sort of race condition
between the nightly run being completed and the way the ruleqa app works
to display the results and I just happened to hit it at the wrong time.
-- sidney
Re: svn commit: r534718 - /spamassassin/rules/trunk/sandbox/sidney/70_other.cf
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Sidney Markowitz wrote:
> Daryl C. W. O'Shea wrote, On 4/5/07 7:11 AM:
>> I don't even know why they're listed in 20070502-r534356-n since those
>> rules weren't checked in until r534718.
> [...]
>> They were checked in (r534325) when 20070502-r534356-n was selected for
>> the nightly mass checks.
>
> It doesn't bode well for the accuracy of our mass check results if rules
> that are checked in during the middle of a run can find their way into it.
The rules aren't in the mass-check logs for r534356 (at least not in the
copy I have from 23:00 UTC yesterday), rather something with the ruleqa
app is apparently screwed up.
Daryl
Re: svn commit: r534718 - /spamassassin/rules/trunk/sandbox/sidney/70_other.cf
Posted by Sidney Markowitz <si...@sidney.com>.
Daryl C. W. O'Shea wrote, On 4/5/07 7:11 AM:
> I don't even know why they're listed in 20070502-r534356-n since those
> rules weren't checked in until r534718.
[...]
> They were checked in (r534325) when 20070502-r534356-n was selected for
> the nightly mass checks.
It doesn't bode well for the accuracy of our mass check results if rules
that are checked in during the middle of a run can find their way into it.
-- sidney
Re: svn commit: r534718 - /spamassassin/rules/trunk/sandbox/sidney/70_other.cf
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Sidney Markowitz wrote:
> Justin Mason wrote, On 3/5/07 9:45 PM:
>> actually, that should be fine... metas can depend on metas.
>
> That's strange, now I can't find where I saw it written that it can't. I
> found it while looking for information on the meta rule syntax to try to
> figure out why those tests were producing inconsistent results.
>
> In any case, now I really don't understand the results. Look at this one
> from the last nightly mass check. To see just what I'm testing at the
> Rule QA web page, use the filter
>
> http://ruleqa.spamassassin.org/20070502-r534356-n/%2F(SIDNEY_%5BA-Z%5D%7CEXTRA_MPART_TYPE)
>
>
> First, why do the T_SIDNEY_NOE_NEMPT through T_SIDNEY_NOE_HTML_EMPT
> rules score what they do (all spam, no ham, S/O 1.00, and especially
> that first one which claims to get 40% of all spam and 0% ham? If we
> really had a rule that could do that we would be in great shape, but
> somehow I don't think that "Not Outlook Express and having no
> EXTRA_MPART_TYPE" is really a test that matches 40% of all spam and 0%
> of all ham :-)
I don't even know why they're listed in 20070502-r534356-n since those
rules weren't checked in until r534718.
> Second, why are the T_SIDNEY_NOT_OE_WITHEXTRA_MPART_TYPE_WITH_HTML
> through T_SIDNEY_OE_WITHOUT_EXTRA_MPART_TYPE rules still in the mass
> check when they are no longer in the sandbox file that I checked in?
They were checked in (r534325) when 20070502-r534356-n was selected for
the nightly mass checks.
Daryl
Re: svn commit: r534718 - /spamassassin/rules/trunk/sandbox/sidney/70_other.cf
Posted by Sidney Markowitz <si...@sidney.com>.
Justin Mason wrote, On 3/5/07 9:45 PM:
> actually, that should be fine... metas can depend on metas.
That's strange, now I can't find where I saw it written that it can't. I
found it while looking for information on the meta rule syntax to try to
figure out why those tests were producing inconsistent results.
In any case, now I really don't understand the results. Look at this one
from the last nightly mass check. To see just what I'm testing at the
Rule QA web page, use the filter
http://ruleqa.spamassassin.org/20070502-r534356-n/%2F(SIDNEY_%5BA-Z%5D%7CEXTRA_MPART_TYPE)
First, why do the T_SIDNEY_NOE_NEMPT through T_SIDNEY_NOE_HTML_EMPT
rules score what they do (all spam, no ham, S/O 1.00, and especially
that first one which claims to get 40% of all spam and 0% ham? If we
really had a rule that could do that we would be in great shape, but
somehow I don't think that "Not Outlook Express and having no
EXTRA_MPART_TYPE" is really a test that matches 40% of all spam and 0%
of all ham :-)
Second, why are the T_SIDNEY_NOT_OE_WITHEXTRA_MPART_TYPE_WITH_HTML
through T_SIDNEY_OE_WITHOUT_EXTRA_MPART_TYPE rules still in the mass
check when they are no longer in the sandbox file that I checked in?
-- sidney