Bug 438864

Summary: timing estimates are bad
Product: [Fedora] Fedora Reporter: Bill Nottingham <notting>
Component: gnome-packagekitAssignee: Robin Norwood <robin.norwood>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: john.mellor, richard, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-11 04:29:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
what I've added to git none

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