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): gnome-packagekit-0.1.9-4.fc9.x86_64
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 estimate
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