No, I wont pardon your bad mood, since it clearly influences your thoughts badly. It takes longer to make a dist when there are processes running around taking most CPU. It is not a design flaw. Your comments, no matter how clever, are irrelevant.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-10-12 17:51: Subject: Broken tests
Pardon my bad mood, but you're chasing symptoms, not the problem. This bug isn't new, particularly related to processes hogging pelix, but is a more or less annoying recurring flaw in how pikefarm (xenofarm?) enforces checkin latencies.
I understand that the current process correctly detects the last known checkin and how long to wait after that, but does not correctly detect when the last build was generated, since it equates the time when the package was made available with the time its generation cycle was initiated, This will remain a bad aproximation for the foreseeable future.
A process that would work better:
- enforce latencies before kicking off a new build (steps 2-4)
- cvs co -D"$DATETIME"
(DATETIME=Calendar.ISO_UTC.dwim_time(T)->set_timezone("localtime"); T=Protocols.HTTP.get_url_data(URL); URL="http://pike.ida.liu.se/development/cvs/latest-Pike-commit") 3) prepare the package 4) export the package, marked as $DATETIME in the pikefarm UI (same value, kept from above)
At present, the time spent running steps 2-4 breaks step 1 of the next cycle. This procedure would work regardless of extraordinary CPU hogs, like my xemacs runner-up eating 0.49% CPU time, or comstedts, however intense it might have been. It is also required to get links between pikefarm and the CVS browser to work. (Having the UI module know only UTC time would also help, of course, but I feel enough at ease hacking there to do so myself if need be, whereas I don't know my way around in the server.pike domain.)
/ Johan Sundström (ärkehertig av Lysators rootgrupp)