Bug 438864 - timing estimates are bad
Summary: timing estimates are bad
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-packagekit
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Robin Norwood
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-25 17:28 UTC by Bill Nottingham
Modified: 2014-03-17 03:13 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-04-11 04:29:59 UTC
Type: ---
Embargoed:


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

Description Bill Nottingham 2008-03-25 17:28:42 UTC
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

Comment 1 Matthias Clasen 2008-03-28 03:36:22 UTC
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 10:26:51 UTC
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 23:29:23 UTC
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

Comment 4 John Mellor 2008-03-31 23:33:02 UTC
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 23:44:41 UTC
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 05:37:11 UTC
I assume you mean 0.1.11 ? 0.1.10 still has it, I believe.

Comment 7 Matthias Clasen 2008-04-11 04:29:59 UTC
times are gone in rawhide


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