https://bugs.kde.org/show_bug.cgi?id=397969
Jasem Mutlaq changed:
What|Removed |Added
Status|NEEDSINFO |RESOLVED
Resolution|WAITINGFORINFO
https://bugs.kde.org/show_bug.cgi?id=397969
--- Comment #7 from TallFurryMan ---
Yeah good idea, I'll open a new issue for this.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=397969
Jasem Mutlaq changed:
What|Removed |Added
Status|REPORTED|NEEDSINFO
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=397969
--- Comment #5 from TallFurryMan ---
In the original code, observatory startup and job processing are two different
state machines in the same module. My guess is that we should go as far as
making observatory management a separate module and tab.
If y
https://bugs.kde.org/show_bug.cgi?id=397969
--- Comment #4 from Jasem Mutlaq ---
IIRC, when the scheduler sleeps while it is active, it parks the mount only.
PARK_WAIT.. if this includes parking dome, then sure when it wakes up, it would
unpark dome as well.
At any rate, I don't see a problem wi
https://bugs.kde.org/show_bug.cgi?id=397969
--- Comment #3 from TallFurryMan ---
To clarify, the state machine of the startup sequence is not event-driven. It
requests operations and considers that once they are done, they are immuable.
As a result, scheduler is only looking at the state of the s
https://bugs.kde.org/show_bug.cgi?id=397969
--- Comment #2 from TallFurryMan ---
The danger lies in the following sequence:
- start the scheduler
- scheduler starts the observatory, opens the dome
- jobs start, eventually the scheduler sleeps
- an external script or the end-user closes the dome
-
https://bugs.kde.org/show_bug.cgi?id=397969
--- Comment #1 from Jasem Mutlaq ---
When starting a job, the startup sequence is checked for success first. So if
it went fine, then all the required steps were taken. So how is it that when
starting a job, the dome is not checked? It was already handl
