On Wednesday 23 January 2008 14:15:38 wrote Dr. Peter Poeml:
On Wed, Jan 23, 2008 at 02:06:30PM +0100, Adrian Schröter wrote:
On Wednesday 23 January 2008 14:00:40 wrote Dirk Stoecker:
On Wed, 23 Jan 2008, Dr. Peter Poeml wrote:
However, it is very irritating when the status is not updated promptly. I have to poll and poll, and don't see anything happening anyhow. Commands that I issue don't seem to have any effect (trigger rebuild). I don't even see if the buildservice _intends_ to build something. Even if it happens eventually, I'm already used to the fact that it may happen after a minute, after a day, you never know.
And, there is no way the buildservice tells me what's up, without the need to poll for every bit, causing additional effort.
That makes working with the buildservice quite hard, frankly. I feel I could easily do the same work in 50% of the time.
What can we do to improve on this?
Yes. Please.
Rebuild triggers not showing as scheduled, finished packages not changing finished into error/successful, adding/removing packages not showing up, ... That all is very disturbing. Somewhere here must be a big communication problem, which needs to be fixed.
A userinterface not responding to user request is very bad design.
well, the calculation of the dependencies completely is not a simple task. Michael has some ideas how to improve it, but figuring out the correct status immediatly will not be possible most likely.
What is thinkable from my personal view is to introduce a "dirty" flag, what marks the current status as invalid and to be calculated ...
After a "trigger rebuild" request, the status is quite obvious to me: "scheduled".
beside that the "trigger rebuild" is a work around for bugs we should fix, the state can still be "broken", "blocked" or "expansion error". It would be even worse to show a state, which is not the fact in the backend .. because people think they could fix their expansion errors with that ;) (but it would have no effect).
My brain seems to be fast enough for that :-)
Of course, subsequent actions (like a dependent package being triggered) doesn't need to happen instantly -- that's not what I expect.
But the obvious bits (like the package explicitely triggered) should be reflected in the user interface.
as said before, I would like to get rid of that at all, because there should be no valid use case for it, except bugs. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org