[packagekit] gnome-packagekit flames^Wreview

Tue Jan 1 12:49:14 PST 2008

On Tue, 2008-01-01 at 19:49 +0000, Richard Hughes wrote:
> Maybe a silly question, but how do I convince the client to exit and
> then restart? Can I use g_spawn_async?

Maybe just use a function from the exec(3) family with a saved argv[0]?

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

I think you still want it; IIRC stable releases (e.g. not Rawhide)
sometimes issue security updates in real time instead of a daily dump.

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

I guess you can make it as fine grained as you want but from a user
interface point of view I think only "Bug Fix Update", "Feature Update"
and "Security Update" matters; also, I think the qualifiers (e.g. "Bug
Fix", "Feature", "Security") are useful for telling the user what the
nature of the update is (qualifiers like "Important" doesn't really make
sense, it greatly differs what's important to different people).

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

The intention of displaying the download size was to give the user an
indication of what's involved in applying the update. Which I think is
pretty important especially if you are on dial-up or metered access. The
latter reason alone is reason enough to keep the download size.

(Also, I think most gf's (e.g. the user we're designing for) are capable
of figuring out that 5MB is something like fast and 500MB is "I have
time to watch two episodes of Project Runway".)

Since we can't really at this point guess what speed we're going to
download at (depends on the Internet weather and the mirrors etc.) maybe
we could be helpful

 The selected set includes 2 security updates and 72 bug fix updates.
 This will require downloading 682MB of data. Depending on your network
 connection and the speed of the server this will take approximately

  - 56k modem:          27 hours, 48 minutes
  - 0.5MBps ADSL/Cable: 22 minutes

I don't know. Seems like a lot of text. But seems pretty important to me
if you want to make this work for people on low-bandwidth / metered
access. Maybe a future feature could estimate the size of the pipe we
have to the mirror server we're going to use and we can make it
prettier. Anyway, the estimates will work for now.

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

Please explain how it "compromises the other use-cases too much". We're
talking about a single checkbox for each package. 

Btw, you're also ignoring users on metered / low-bandwidth connections
who only wants a single update for e.g. tzdata because their country's
government fucked up [1] and they want their computer to display the
correct time ASAP:

https://www.redhat.com/archives/fedora-devel-list/2007-December/msg01771.html

Also, you're ignoring people who run a production system and e.g. wants
the tzdata update immediately but wants to wait a week or two with the
other updates because they want to test them on non-production systems.

Then there's also reality to deal with

https://www.redhat.com/archives/fedora-devel-list/2007-December/msg01706.html

and the fact that people make mistakes.

Designing good software not only includes making it easy for the
girlfriend / aunt tillie kind of users (who I think you are making too
dumb, e.g. see above) to use it. It also includes making it possible for
advanced users to make the software do what they want instead of making
them send angry rants the developers way. Good design is about marrying
these two concepts so they don't step on each other toes too much. 

Then there's also the angle of winning the minds and hearts of GNOME
software developers and distributions. Realize that these people, the
ubergeeks as you put it, constitute probably 90%+ of your user base.
They are either on Rawhide (or Debian unstable / experimental, Mandrive
Cooker etc. etc.) so what you are suggesting just won't work for them.
Otherwise they are on a stable distribution and they install 3rd party
crap that will produce other conflicts.

I think, if anything, GNOME 2.0 showed the world that _only_ designing
for girlfriend / aunt tillie users was a mistake. Something which took a
lot of revisions in the GNOME 2.x to fix.

Anyway, it's your software but I'm hoping this is enough to make you
realize that alienating 90% of your users from day one is a bad idea.

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

No, I'm not asking for your software to guess on my behalf; it's fine,
in the case of broken deps, to just leave the guessing to the user. IOW:
Kindly include a damned set of check boxes and leave it to the user to
figure out what he wants.

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

No, that's not what I meant. I just meant that the details view for a
package update would probably include one or more tabs, one named
"Advisory", one named "Package Changes" and so on.

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

Oh, so if you think it makes total sense why did you argue against
deselecting updates above? Hmm.. maybe my big speech about why it should
be included wasn't necessary :-)

> 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! :-)

Yeah, sorry, I was just trying to keep the thread readable.

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

Cool, thanks for considering.

> Ohh, and HAPPY NEW YEAR!! :-)

You, and others on the list, too!

Cheers,
David