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 :(
--j.
