Progress of checking for updates is indeterminate
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu system image |
Triaged
|
Low
|
Unassigned | ||
ubuntu-system-settings (Ubuntu) |
Confirmed
|
Low
|
Matthew Paul Thomas |
Bug Description
1. Open "System Settings" > "Updates" to check for updates.
What happens: Progress is shown with an indeterminate spinner.
What should happen: Ideally, progress is shown in a determinate way.
Barry Warsaw in bug 1272313: "Checking for whether an update is available is a complicated, multi-step
process. For example, there are potentially 4 gpg keyring files that must be present, but only one that is shipped with the image, so the 'check for update available' process must be able to backtrack and download any missing keys."
So the first step in fixing this is to tabulate the steps involved:
| Step | Probability the step is required at all | Distribution of time it takes |
Then assign to me for design.
Changed in ubuntu-system-settings (Ubuntu): | |
importance: | Undecided → Low |
status: | New → Confirmed |
tags: | added: client |
Changed in ubuntu-system-image: | |
assignee: | nobody → Barry Warsaw (barry) |
Changed in ubuntu-system-settings (Ubuntu): | |
assignee: | Barry Warsaw (barry) → nobody |
Changed in ubuntu-system-image: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in ubuntu-system-image: | |
importance: | Medium → Low |
assignee: | Barry Warsaw (barry) → nobody |
Changed in ubuntu-system-settings (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in ubuntu-system-settings (Ubuntu): | |
assignee: | nobody → Matthew Paul Thomas (mpt) |
status: | Triaged → Confirmed |
tags: | added: updater |
tags: |
added: update removed: updater |
tags: |
added: updates removed: update |
From Barry in bug 1272313:
------------
The tricky part is that we won't know how many steps are involved ahead of
time. For example, let's say we have three of the four keys already when we
start the check. The first thing we do is download the blacklist, and if one
of the three keys is now on the blacklist, we'll have an extra step to
download a replacement. Also, it's possible that once we've downloaded the
first key, it might make subsequent key checks fail validation.
There's an upper limit to the number of things we have to download during the
check though, so we could just emit something like:
step 1 of 7
step 2 of 7
(steps 3-5 can be skipped so...)
step 6 of 7
step 7 of 7
It might make the display a bit jumpy, but it would be feasible without much
work. For backward compatibility we'd have to add new dbus signals for these
progress steps.
------------