[packagekit] gnome-packagekit flames^Wreview

[Richard Hughes]

On Mon, 2007-12-31 at 12:57 -0500, David Zeuthen wrote: 
> >  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?

Maybe a silly question, but how do I convince the client to exit and
then restart? Can I use g_spawn_async?

> > >     - 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.

I'm tempted to just ditch the button as PackageKit seems to do quite a
good job refreshing only when sensible.

> > 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.

Agree, I've removed it in b0c9a33bf8922ab8376d022cb4bc08c782cedd73

> > 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.

I'm thinking;

low -> Bugfix
normal -> Update
high -> Important Update
security -> Security 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'm not sure about displaying the total download size, it doesn't mean a
lot to people like my girlfriend.

> (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.)

Sure.

> > 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. 

Sure, I think we need to agree to disagree on that issue :-)

> 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. 

Sure, you are using yum on rawhide; that's not the typical user for
PackageKit. The average user for PackageKit is my girlfriend; she
doesn't know how much a megabyte costs, and she won't read the security
advisories, she has automatic updates turned on. Then there's the casual
linux user who wants to see what is being updated and why. Then there's
the friendly boyfriend who installs software for then to do things.

I don't see the uber-geek (i.e. me and you) as a primary use case - as
then it compromises the other use-cases too much.

> 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".

No, fixing brokenness is the job for the software, not the user. If I
can't update because of a broken dep to xulrunner then it should
unselect firefox for me, as sometimes the link between the broken dep
and the packageset isn't obvious.

> > >       - 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".

Do you mean the Details should be renamed Advisory or do I
misunderstand?

> > >  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.

Sure, I've thought about this and it makes total sense.

> (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).

Sure, it needs to be more task focused.

> 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. 

Ohh, sorry. To be honest, I do find these emails useful as we can
discuss issues and other problems - and I hope you can see some of your
suggested changes actually hitting git. It may be more useful if we
break up replies for the sake of sanity! :-)

> 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.

A good one. I'll have a think on how I can work this into the current
codebase. I've never used GtkAssistant before, so I might get it wrong
a few times before we get it correct.

Ohh, and HAPPY NEW YEAR!! :-)

Richard.