Red Hat Bugzilla – Bug 438864
timing estimates are bad
Last modified: 2014-03-16 23:13:11 EDT
Description of problem:
Right now mine's been stuck on 30 seconds for a few minutes.
Version-Release number of selected component (if applicable):
I vote for simply removing them. Another visual issue is that the time estimates
make the first progressbar higher than the second one, which looks unbalanced.
Created attachment 299445 [details]
what I've added to git
I've added the following patch to PackageKit git, which turns off the time
remaining calculation unless you are a developer.
For the impending release, developer stuff obviously will not be built.
The download time would appear to be calculated starting from some ridiculous
download speed, and then does not learn the true download rate appropriately.
My 8Mb uplink is nowhere near fast enough to give a reasonable download time
I use a slow testbed box specifically to uncover poor time estimate problems
from developers with kickass boxes who do not understand what a more realistic
machine can actually see. The compute-bound time between download completion
and updating is huge and not documented. It needs a separate window state
adding to account for this period in a reasonable way.
John, I've turned off the time reporting for 0.1.10 - the time reporting relies
on the backend, and so is only as accurate as the backend suggests.
I assume you mean 0.1.11 ? 0.1.10 still has it, I believe.
times are gone in rawhide