Mailinglist Archive: opensuse-buildservice (314 mails)

< Previous Next >
Re: [opensuse-buildservice] Slowness
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Wed, 23 Jan 2008 14:41:50 +0100
  • Message-id: <200801231441.50888.adrian@xxxxxxx>
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@xxxxxxx

---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups