On Fri, Jan 30, 2009 at 06:22:57PM +0100, Lars Marowsky-Bree wrote:
what's the reason for the latency in status displays on b.o.o?
Implementation details, I'd say ;)
When I enable building for a previously disabled arch, it took several minutes to update the status from "disabled" to building/blocked.
I understand that this is partly due to the scheduler re-run needed, but because that time is not known or exposed, one looks through all the expert settings to figure out what one has done wrong, or if there isn't a flag one overlooked.
Sometimes the same happens between "finished" to "succeeded", or when the build has finished when the buid log seems to switch from "live" to "archived", there's a gap there the build has finished (possibly failed) but the log then still shows the outdated one - which build fine or aborted with a different error.
It's a usability nightmare.
I agree, and I have moaned quite a lot about this in the past. As long as the state is unclear, it would be much better to know about that fact, instead of getting a state that is clearly wrong. In addition, I would suggest to introduce a new state "published" because the publishing step often takes considerable time. It sucks to need to walk through the web server and compare timestamps and mtimes in an error-prone way just to see whether packages are already available - often the next step of testing a package, or notifying somebody else for testing, is tied to this step.
Can't we at least - if the latencies can't be reduced for some reason - immediately wipe the outdated state? I'd rather see a "Please wait" message until the next scheduler run instead of wrong information.
It would be very useful in my view. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development