Bug 438864 - timing estimates are bad
timing estimates are bad
Product: Fedora
Classification: Fedora
Component: gnome-packagekit (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Robin Norwood
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-03-25 13:28 EDT by Bill Nottingham
Modified: 2014-03-16 23:13 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-11 00:29:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
what I've added to git (1.08 KB, patch)
2008-03-28 06:26 EDT, Richard Hughes
no flags Details | Diff

  None (edit)
Description Bill Nottingham 2008-03-25 13:28:42 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):

Comment 1 Matthias Clasen 2008-03-27 23:36:22 EDT
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.
Comment 2 Richard Hughes 2008-03-28 06:26:51 EDT
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.
Comment 3 John Mellor 2008-03-31 19:29:23 EDT
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
Comment 4 John Mellor 2008-03-31 19:33:02 EDT
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.
Comment 5 Richard Hughes 2008-03-31 19:44:41 EDT
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.
Comment 6 Matthias Clasen 2008-04-01 01:37:11 EDT
I assume you mean 0.1.11 ? 0.1.10 still has it, I believe.
Comment 7 Matthias Clasen 2008-04-11 00:29:59 EDT
times are gone in rawhide

Note You need to log in before you can comment on or make changes to this bug.