On 6/27/2011 6:03 PM, Warren Togami Jr. wrote:
On 6/27/2011 11:52 AM, Kevin A. McGrail wrote:
It's back as a T_rule because someone removed(?) the nopublish flag.

SEM was supposed to be a net nopublish rule.

So the publication as T_RULE is not a bug in the code but "correct"
behavior because the sandbox is missing the nopublish flag because of
bug 6297 and bug 6257.

Not exactly. #testrules is supposed to have the same effect as "tflags nopublish", but for an entire sandbox file.
I don't concur. It makes them T_ rules which is what occurred and what the code appears to do. According to Justin:

If a sandbox file contains the comment "#testrules", all rules defined beyond
that point will be considered testing rules by the "listpromotable" script, as
if they were named with the "T_" prefix (but without requiring that).



A make build_rules on trunk no longer includes SEM rules in
72_active.cf. It is also still missing from 70_sandbox.cf.


Are you sure it wont be auto-promoted though? That's a different code path than "make build".
I've doubled-checked quite a bit but I'm late for a swim meet for my daughter so as this is no longer an emergency, we can check tomorrow and start there. Right now, it's not a load on SEM's network they can't handle, the scores are negligible and he's not going to block queries for a few weeks.

That's how the March 2011 trouble happened.
I think the March trouble occurred because nopublish was removed and #testrules added and then #testrules didn't work as expected. The code definitely does not agree with what others appear to think it should do.


BTW, r1104058 rules were generated prior to June 11th when jm completely removed JM_SOUGHT_FRAUD* and __SEEK_FRAUD* in order to eliminate the sa-update channel ordering issue. As we are pushing an emergency rule update anyway, we should take this opportunity to do this as well.

We have no need to push out an emergency rule update and we have already pushed out updates beyond r1104058. Channel 1139459.

Regards,
KAM

Reply via email to