Merge lp:~ted/unity8/delay-indicator-start into lp:unity8
| Status: | Merged |
|---|---|
| Approved by: | Michael Terry on 2015-12-07 |
| Approved revision: | 1422 |
| Merged at revision: | 2179 |
| Proposed branch: | lp:~ted/unity8/delay-indicator-start |
| Merge into: | lp:unity8 |
| Diff against target: |
21 lines (+5/-3) 1 file modified
data/unity8.conf (+5/-3) |
| To merge this branch: | bzr merge lp:~ted/unity8/delay-indicator-start |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Michael Terry | Approve on 2015-12-07 | ||
| PS Jenkins bot | continuous-integration | Needs Fixing on 2015-09-17 | |
| Michał Sawicz | concept | 2014-11-07 | Approve on 2015-02-09 |
|
Review via email:
|
|||
Commit Message
Start the indicators after Unity8 starts instead of before
Description of the Change
In many cases the indicators are having issues with notifications and sound because they're started too early, they shouldn't be needed until Unity is up and running anyway, so let's ensure that we give all the CPU we can to Unity.
| Ted Gould (ted) wrote : | # |
Well, the problem is that you're emitting it *before* Unity8 starting, not on it starting. We're seeing a couple of issues. One is that we see the notification service as the name is registered but it's not ready to send capabilities yet so we get incorrect capabilities. The only way to work around that would be to requery the capabilities periodically (ugly).
Generally, the indicators shouldn't be started at the same time as Unity8 just so that Unity8 gets all the CPU it needs to start and render the lock screen. The indicators should start after it as they're not as critical.
| Ted Gould (ted) wrote : | # |
Uhg, I was able to break it with this fix. Seems less likely, but not entirely gone.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:1422
http://
Executed test runs:
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
UNSTABLE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Ted Gould (ted) wrote : | # |
We discussed this a bit on IRC. While this isn't a "fix" it seems to be an overall "improvement" as there's no reason to start indicators before Unity8, give it a bit of a head start.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:1422
http://
Executed test runs:
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
UNSTABLE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Michał Sawicz (saviq) wrote : | # |
I'm fine with that. Didn't it cause some boot issues last time we tried this?
| Ted Gould (ted) wrote : | # |
On Mon, 2015-02-09 at 16:12 +0000, Michał Sawicz wrote:
> I'm fine with that. Didn't it cause some boot issues last time we tried this?
I believe it was more that it didn't solve the startup problem we had
with indicator-sound getting the notification server before it started.
The fix for that problem was implemented in indicator-sound, so now it
handles notification servers starting and stopping on the fly.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:1422
http://
Executed test runs:
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
UNSTABLE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:1422
http://
Executed test runs:
UNSTABLE: http://
FAILURE: http://
FAILURE: http://
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
UNSTABLE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Michael Terry (mterry) wrote : | # |
Makes sense and works for me.
I will note that in theory Design might care about this sort of stuff. I imagine they would rather have unity8 and the indicators coordinate themselves to only render on screen once they are all there and ready to go, rather than popping in whenever they feel like it.
But this branch doesn't really make them pop in drastically slower than before, so I guess that's not an issue for this MP.
We asked explicitly, when adding this signal, when would be a good time. We were told that on unity8 starting was good enough.
Could the indicators not try and re-connect to the needed services?