[packagekit] gnome-packagekit flames^Wreview

[David Zeuthen]

On Mon, 2007-12-31 at 11:33 +0000, Richard Hughes wrote:
> >  o  You should probably do something like sending a HUP signal
> >     to both the PackageKit daemon and the pk-update-icon daemon
> >     to make them reload on package upgrades
> 
> Well, packagekitd will auto-quit if it's doing nothing, so I think we
> just have to wait for that.

Fair enough.

>  I'm not sure how we could make
> pk-update-icon restart (on all desktops) in a sane way - maybe we could
> give a DBUS signal or something. Is there a sane way to detect "hey, my
> binary has changed"?

D-Bus and inotify is very nice, but how about just a low-tech solution
like

 killall -HUP pk-update-icon

in %post and then catch the HUP signal?

> >  o  There's an "Add/Remove Software" in the System->Administration
> >     menu. This menu item should be in the bottom of the Applications
> >     menu instead (just like pirut).
> 
> Well, I would argue that installing and removing software /is/ system
> administration rather than anything special enough to get a menu root
> position. What was the rationale to making pirut a root level menu item?
> Surely we should just reserve that spot for the simple "application
> chooser" that we have yet to built.

Curious; how would that differ from "Add/Remove Software"? Why would I
use one over the other? (IOW: who are you designing for?)

> >     So this is just pretty confusing. Suggestions
> > 
> >     - kill the icon for the "Software Transaction Viewer completely" and
> >       make the functionality available via a button or something in the
> >       "Software Update Viewer".
> 
> What, make it launch from a button like "Past Transactions"?

Yeah, something like that.

> >       Also, I'm pretty sure it shouldn't be in the Applications->System
> >       Tools menu. Suggest to use a verb instead (it is really an action
> >       and not a tool) and place it in the System menu. E.g. have a
> >       "Update this system" right next to the "Lock Screen", "Log
> >       Out davidz" and "Suspend System" items. 
> 
> Well, the point is that normal users won't ever have to use this tool as
> the updates will just be done automatically.

First, it's pretty reassuring for users to be able to easily get to some
UI and see a green light saying "Everything is up to date". Plus, if
migrating the way to get to "Software Transaction Viewer" from a menu
item into a button in "Software Update Viewer" you'd need it to get to
that...

> >     - What does the "Refresh" button do and why would I need to refresh
> >       something? In the unlikely event that there are suddenly newer
> >       updates while I have this window open it should just automatically
> >       update itself.
> 
> It does, a refresh from PackageKit suggests to the session application
> that it might like to get the new data and update the UI. The refresh
> button lets you ask the daemon to drop all caches and get the new
> metadata, like if you've just updated a local repo. Maybe we can punt
> this button or give it a better name.

It's not always bad to be verbose; especially when it concerns such hard
to grok concepts as cache coherency. Suggestion:

   Software meta data was last refreshed from the network on Mon Dec 31
   2007 at 9:05 AM.
                                                         [Force Refresh]

and add a TODO to mention in the Yelp file why this is in the UI.

> Valid point. I've made it non-sensitive until we have a sensible yelp
> file.

Thanks, but I'd just remove them for now. Users will just file bugs
because their insensitive.

> Well, we don't know much about the update. We know if it's a low,
> normal, high or security update - but I think the yum backend considers
> them all "normal".

If you don't have advisories at all, maybe you should just remove the
severity column then. Or you should just consider it to be a "bug fix"
update.

> 
> >    -  It would be useful to know how many updates there are in the
> >       batch and how much time it would take to apply them. So suggest
> >       to include a textual element in the top explaining to the user
> >       what is going on (more on that later)
> 
> Like a summary at the top?, like:
> 
> [ security icon ] 2 security updates
> [ low prio icon ] 3 low priority updates

Suggest to just use text

 There are 2 security updates and 72 bug fix updates available. This
 will require downloading 682MB of data.

(I'd also avoid wording like "low priority"; choose a nomenclature and
document it in the HACKING file or the developer docs somewhere, e.g.
two categories (or whatever): Security and Bug Fix.)

> Well, we can't just cherry pick updates - I've explained on the list a
> few weeks ago why this is very difficult and bad thing to do; you are
> making the user work around the repository brokenness. It's better to
> let the software work around it in a clever way like I can do with "yum
> --skip-broken update"

And I think that explanation is still bogus. 

Look at it this way: It's perfectly fine for me to cherry pick updates
when using yum(8) on the command line; sometimes I just need to exclude
updates to get it working on Rawhide. I don't see why it would be any
different using the PackageKit UI. 

I'm not asking for you to compute the largest closed sets of updates for
me. But I'm expecting the UI to

 1.  let me choose the updates I want
 2.  attempt to do the update
 3.  let me know if the chosen set cannot be updated
 4.  then I can deselect certain updates by inspecting the error message
 5.  and try again... (goto 2.)

Notably this includes not making the "Software Update Viewer" window go
away when I press "Apply".

> >       - You want to display Bodhi style advisory information [2]; you
> >         perhaps already have this... but what happens if I'm two
> >         advisories behind? Do I get to see two advisories? Assuming you
> >         display advisories for some streams, at least the UI should tell
> >         me about this even when using a stream (like Rawhide) without
> >         advisories; e.g. an empty tab for advisory information (more on
> >         that later)
> 
> Well, the metadata should already be being displayed for fedora 8,
> although this doesn't seem to be working for me. I think the
> GetUpdateDetail method just gets the metadata for that specific update,
> although I'm guessing it would be possible to get it for all packages >
> installed but < available. That's a backend thing tho.

Btw, suggest to introduce nomenclature and stick with it; e.g. what
comes out of Bodhi should be referred to as an "Advisory".

> >  o  Fine, so now I press "Apply" guessing that it will update my
> > system.
> >     Wow, the window just disappeared. Very confusing; did the
> >     application just crash?
> 
> I figured once the update was underway we could just close that window;
> if the update fails to be scheduled then the window is not closed. Did
> you expect to have to close the window manually?

Actually I'd expect the window to be present and show me information
about the update process that I just started. I think that's a fair
assumption because the act of wanting to update the system is a
task-driven thing. Keeping the window around, including the state, will
also easily allow the user to go back and deselect certain updates sets
that would error out.

(As I rambled about in the initial mail, the user experience in 0.1.5
isn't task-driven at all; it's like you designed the entire UI around a
client<->server system and mapped the D-Bus 1:1 to the user interface).

> Yes, this is a bug I've mentioned a couple of times on the list
> before:
> sometimes the yum backend does not emit a "Package" signal telling us
> what it downloaded or is installing. It's a yum backend problem.

So maybe you shouldn't do a release with such dire bugs present? I know
all about the "release early, release often" mentality and it's fine
but.. really.. I think things like that qualify as release blockers. It
just makes the product as a whole feel very unfinished and unpolished.

As for the rest of the issues I ranted about. Your response seems to
raise even more questions and me replying point-by-point would render
this thread more difficult to manage. 

So as I hinted above and elsewhere I think you need to rethink how the
whole UI works; it seems you're trading off usability for the ability to
make the UI bits completely stateless and easily work for the rare
heisen-cases where you queue several transactions (be them updates or
installing new software). E.g. the UI really feels like you more or less
map the D-Bus API's 1:1 to user interface elements.

I'd initially focus on making the software updater work really well. I
think one nice solution for this is to make the "Software Update
Viewer" (e.g. what I'd call "Update System") a task driven wizard
interface (e.g. GtkAssistant) that looks like this

 o  Page 1: Diligently explaining the user what's going on
    - When was the metadata last updated from the network? Give me
      a chance to refresh it
    - How many updates do I have? What's involved in getting them?
    - What's the nature of each package update?
      - advisories
      - changelogs
      - conflicts, requires
    - There are two buttons at the bottom of the assistant
     - Update System: takes me to the next page where the items I
       selected will be updated.
     - Close: will simply dismiss the window

 o  Page 2: The Update. Should probably look like the "PackageKit
    Progress" dialog along with progress bars and useful text
    telling me what's going on.
    - There will be two buttons
       - Cancel: Cancels the transaction and goes back to the previous
                 page
       - Close: Will let the transaction run in the background. I can
                still go back to it by clicking the notification icon.
    - Suggest use of tooltips to convey what the Cancel and Close
      buttons do. Maybe even spell it out in text in the UI.

 o  Page 3: Update summary. Here we go when the transaction is
    finished either successfully or if it failed

    - If the transaction fails, the main UI will tell me why it
      failed. The main UI will tell me that I can hit [Back] to
      go back and refine my updates. If I previously dismissed
      the window through [Close] on Page 2 then I can get to this
      screen by clicking the pk-update-icon which should have an
      exclamation mark or something.

      (For bonus points it could be clever and deselect the packages
      that makes the transaction fail.)

      I will also have a [Close] button whereby I can acknowledge
      that the update didn't work and that I'm fine with that (and
      the pk-update-icon exclamation thing will go away)

    - If the transaction succeeded, then we show how many packages we
      updated and greet the user. There's a single [Close] button to
      dismiss the window.

Anyway, just an idea.

     David