On Tue, Apr 7, 2009 at 09:48, Justin Mason <[email protected]> wrote: > On Tue, Apr 7, 2009 at 02:36, Daryl C. W. O'Shea > <[email protected]> wrote: >> On 06/04/2009 5:35 AM, Justin Mason wrote: >>> 2009/4/6 Justin Mason <[email protected]>: >>>> 2009/4/6 Karsten Bräckelmann <[email protected]>: >>>>> On Sun, 2009-04-05 at 20:59 -0400, Daryl C. W. O'Shea wrote: >>>>>> Apparently something is broken... I've only checked my mass-check server >>>>>> output from the last 10 days, but I've certainly uploaded my results for >>>>>> my million messages each of those days. >>>>> Possibly related to "Moving heavy I/O-operations"? >>>> I'll take a look :( >>> >>> something's definitely up as a load of them seem to be listed as "zmi" only. >>> I think it's "forgetting" contributors when newer logs arrive. >> >> zmi has in the past submitted logs with the wrong revision number (not >> one of the nightly revisions)... perhaps he is again and its causing >> problems. Although last time it just created an extra line in the >> interface for his revision. >> > > That may be part of it. but it's a general bug that needs to be fixed too :( > > first off the logs are like this: > > ham-jm @ 20090406-r943854-n > ham-dos @ 20090406-r943854-n > ham-somebody @ 20090406-r943854-n > > the corpus-hourly scripts should run at this point and generate a DETAILS > hit-frequencies summary using ham-jm, ham-dos and ham-somebody for > 20090406-r943854-n. > > then the day rolls over, some time passes, and jm, dos and somebody uploads > today's logs: > > ham-jm @ 20090407-r943912-n > ham-dos @ 20090407-r943912-n > ham-somebody @ 20090407-r943912-n > > Now, what should happen is that the previous DETAILS file is still valid. > > then zmi uploads his logs for 20090406-r943854-n: > > ham-jm @ 20090407-r943912-n > ham-dos @ 20090407-r943912-n > ham-somebody @ 20090407-r943912-n > ham-zmi @ 20090406-r943854-n > > At this point the corpus-hourly scripts run again -- and the only log > they can see for 20090406-r943854-n is zmi's. therefore the old info for > the other 3 submitters gets overwritten! > > this is obviously a corpus-hourly bug. what it should do is keep the old > logs from the prev run, and be able to add the new zmi log to them (in > addition). the fact that it can't is a pretty major omission and I'm > surprised this hasn't happened before... > > anyway, for now I've turned off parsing of zmi's logs to try to help a little. > but I need to get some tuits to rewrite this logic entirely :(
hooray! got some tuits. I think this should now be working again, although it could do with some beautification to remove visible daterev duplication in the ruleqa output page... --j.
