spamassassin-sysadmins mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Jones <da...@apache.org>
Subject Re: Eureka: truncation of 72_active.cf
Date Thu, 02 Nov 2017 15:53:19 GMT
Well crap.  I found another odd dependency that throws off the masscheck 
processing thrown off when commits are done outside the few hour window:

https://wiki.apache.org/spamassassin/InfraNotes2017#nitemc

automc@sa-vm1:~$ ~/svn/trunk/build/mkupdates/run_nightly
+ promote_active_rules
+ pwd
/usr/local/spamassassin/automc/svn/trunk
+ /usr/bin/perl build/mkupdates/listpromotable
HTTP get: http://ruleqa.spamassassin.org/1-days-ago?xml=1
no 'mcviewing', 'mcsubmitters' microformats on day 1
URL: http://ruleqa.spamassassin.org/1-days-ago?xml=1
+ exit 25

This is a critical cron job that sets up the new rule promotions daily. 
I will dig into this one deeper but it seems that if the masscheck SA 
revision gets out of sync with new commits that may not even be 
ruleset-related, then days have to pass with no commits before the stars 
will align properly again.  Geez.  What a mess with this workflow!

I think we need to carefully document the current SVN workflow and 
redesign it to handle this better.  The masscheck processing of rulesets 
only needs to be tied to the ruleset revision staged in the rsync area 
for the current 24 hour period.  Maybe we need a new masscheck-specific 
tag separate from the rule promotion tags today?

Rule promotions can happen at any time, multiple times a day as long as 
they pass a lint check.

Masscheck validation are currently only done once a day.

My intial thoughts are parts of the scripts are using the latest SVN 
revision and part are using the latest tagged revision from rule 
promotions.  When these get out of sync, we don't get enough 
masschecking of the proper revision to keep moving everything forward.

Dave


On 11/02/2017 07:46 AM, Kevin A. McGrail wrote:
> On 11/2/2017 8:40 AM, Merijn van den Kroonenberg wrote:
>> The checkout works as you would expect. But its just very confusing a 
>> revision is used which is not inside the spamassassin project.
>> It might also cause side effects in other part of the process as David 
>> mentioned. But the check out part is not actually broken.
>>
>> I do have some considerable experience with subversion....the problem 
>> is more what the intention of the code should be ;)
> 
> My recommendation is do not try and unravel the thought process behind 
> the code.  Stay focused on the goal which is to produce rules and 
> distribute them.  Anything you do towards that goal is good.  If we 
> break some eggs to make some omelets, great.
> 
> Ideally, I would like to publish more daily rulesets, focus on 
> optimization, etc.
> 
> Regards,
> 
> KAM
> 


Mime
View raw message