Bug 212940

Summary: RFE: Pirut/Pup -- Information in Progress Window
Product: [Fedora] Fedora Reporter: Gian Paolo Mureddu <gmureddu>
Component: pirutAssignee: Jeremy Katz <katzj>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
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: 2007-04-09 20:07:39 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:

Description Gian Paolo Mureddu 2006-10-30 08:50:36 UTC
Full summary:

Make Pup and Pirut show more information to the user in the progress window.

Rationale:

Pirut and Pup are probably key to the desktop in Fedora Core, because they're
the applications responsible for delivering system updates as well as the means
to get new software installed into the system from the Internet and the various
repositories. I think that it will be in the best interest of the users to be a
bit more verbose in the progress windows of each programs. For example the
command-line interface of YUM is quite verbose about a series of things, like
size of individual packages, total size for download of the selected packages
and last but definitely not least, the time remaining for the currently
downloading file. Pup and Pirut could immensely benefit from showing information
such as this, and even some advanced controls within the progress window.
Consider the following:

* Size of the individual files. In the case of Pup that also means to have a
number at the very bottom of the window stating the total size of the download.
This can help quite a bit for people who need to plan their updates and only get
the most critical ones and then download the bigger ones. For instance state the
size of a new kernel package and that of OpenOffice.org-core, so the users can
get the most critical first (kernel) and the let the bigger one
(OpenOffice.org-core) for a later, whey they have more time. The same goes for
Pirut, to show the size of the files when they are being selected. Also make it
so that in the confirmation window of Pirut, the total size for the transaction
will be displayed. In both cases a total ETA (at a certain network speed) would
also be desirable.

* Remaining time for the currently downloading file. At the very least, just
beside the name of file currently being downloaded, an ETA could be shown, plus
the size of the file.

* Have an advanced drop-down hidden menu (like the one for file type in GIMP's
Open File menu or OpenOffice.org's) for other actions and information. Such
actions and information would be: current mirror, actual network speed of the
file transfer in kb|mb/sec and a button to switch mirrors if the transfer is too
slow (even make it so it is only lit [available] if the file transfer is bellow
a certain threshold); also information of the currently used yum plug-ins would
be desirable.

Such enhancements will render the applications much more useful. Currently they
do their job just fine, but feel kind of rough around the edges. The proposed
enhancements follow the paradigm of the GNOME desktop in that they wold add more
information and not clutter the interface, leaving it clean, but more useful.

Comment 1 Jeremy Katz 2007-04-09 20:07:39 UTC
The size of the package shouldn't be the driving factor (and longer term, should
be even less so as things like presto are able to be well integrated into the
distribution).  Similarly, estimating download times is not something that can
be done with a high degree of reliability.

Comment 2 Gian Paolo Mureddu 2007-04-10 01:43:37 UTC
It is a major piece of information, especially for countries where broad band
penetration has been slow, and even a 200-300 Mb update could take hours to
perform. In my country the state of things is such that the lowest "broad band"
access is of about 128kbps, and the mean broad band access is of about 512kbps.
Compare this to other countries where 3 or even 8 mbps are common place. In such
conditions a 200-300 Mb update is a snap, while for countries such as Mexico and
other Latinamerican countries it may take quite a while.

Also these enchancements could desperately benefit Anaconda... Though this would
be a totally different RFE, Anaconda could also immensely benefit from being a
bit more verbose and leave the user less in the dark about the estimated time a
download/install will take, especially if the mirrors are selected during
installation... where currently (FC6) it doesn't even display whether a package
is being downloaded or installed from local media.

Maybe Fedora is not the ideal distribution for nations such as ours, but
personally I love Fedora, and also think that these enchacements benefit us all.