[opensuse-buildservice] Slowness
Hi, I used the buildservice productively a lot yesterday and today (eat your own dogfood ;) because I was bringen the Apache project up to date. I constantly face one problem: Slowness. It is obvious that packages can not be built instantly, I'm fine with waiting for them. That's not the problem. 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? Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
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. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
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 ... -- 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
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". 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. Otherwise it doesn't make much sense to look into the user interface at all. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
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
On Wed, 23 Jan 2008, Adrian Schröter wrote:
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.
No please not. You will never get rid of all the bugs. There will be new bugs in the future, ... Introducing a status "changed" or like that, which tells us immediately, that - rebuild has been triggered, - project has been changed, - ... - (what about new/deleted packages?) would be fine without breaking the meaning of the other status flags. Thought fixing the speed problems is still an issue then. Ciao -- http://www.dstoecker.eu/ (PGP key available)
Am Mittwoch, 23. Januar 2008 14:15:38 schrieb 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.
As user I need this feedback. Something like ("Scheduled" /) "Changed" / "Waiting ..." just as ACK for the last request. If the subsequent status flags change too slowly i'd probably retrigger - thats how people "think" ;) .
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". True .
My brain seems to be fast enough for that :-) LOL, see above. Let's upgrade the OBS hardware ;) .
Best regards Jan-Simon --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 2008-01-23 14:52:48 +0100, Jan-Simon Möller wrote:
After a "trigger rebuild" request, the status is quite obvious to me: "scheduled". True .
wrong. it can also be blocked. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Wednesday 23 January 2008 15:29:52 wrote Marcus Rueckert:
On 2008-01-23 14:52:48 +0100, Jan-Simon Möller wrote:
After a "trigger rebuild" request, the status is quite obvious to me: "scheduled".
True .
wrong. it can also be blocked.
or broken or expansion error ... no one reads my mails :/ -- 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
On 2008-01-23 16:02:40 +0100, Adrian Schröter wrote:
On Wednesday 23 January 2008 15:29:52 wrote Marcus Rueckert:
On 2008-01-23 14:52:48 +0100, Jan-Simon Möller wrote:
After a "trigger rebuild" request, the status is quite obvious to me: "scheduled".
True .
wrong. it can also be blocked.
or broken or expansion error ...
no one reads my mails :/
those are a bit more expansive to calculate then the blocked state. though. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Mittwoch 23 Januar 2008 16:12:45 schrieb Marcus Rueckert:
On 2008-01-23 16:02:40 +0100, Adrian Schröter wrote:
On Wednesday 23 January 2008 15:29:52 wrote Marcus Rueckert:
On 2008-01-23 14:52:48 +0100, Jan-Simon Möller wrote:
After a "trigger rebuild" request, the status is quite obvious to me: "scheduled".
True .
wrong. it can also be blocked. or broken or expansion error ... Ok, ok - don't beat us ;)
no one reads my mails :/ <SCNR> Indeed. ;) </SCNR>
Ok, lets paraphrase it: After a e.g. "trigger rebuild" request, the status is to be changed (blocked, expansion, ???, scheduled). - right ? These need to be computed, calculated, queued-up or whatever needs to be done. This adds a delay to that process. - right ? And i can hear darix typing "patience is a virtue" ;). Besides that, we _are_ impatient by nature. ;) The proposal was to add a "Changed" status. This should be displayed as soon as the request was received and during the actual state (blocked, expansion, scheduled,...) being calculated. Nice side-effect: darix won't have to type "patience..." that often ... users of the web-interface know as fast as possible that their input was received and probably won't trigger a 2nd or 3rd rebuild because they see no change in the interface. Best regards Jan-Simon --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (5)
-
Adrian Schröter -
Dirk Stoecker -
Dr. Peter Poeml -
Jan-Simon Möller -
Marcus Rueckert