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
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.
"WARNING: This bug is visible to non-employees. Please be respectful!"
SUSE LINUX Products GmbH
Research & Development