low-hanging fruit

[seth vidal]

On Wed, 2007-08-22 at 10:18 -0400, Owen Taylor wrote:
> On 8/21/07, seth vidal <skvidal at fedoraproject.org> wrote:
> >
> > On Tue, 2007-08-21 at 14:34 -0400, David Zeuthen wrote:
> > > On Tue, 2007-08-21 at 14:04 -0400, Colin Walters wrote:
> > > > On 8/21/07, David Zeuthen <davidz at redhat.com> wrote:
> > > >
> > > >
> > > >         - Note that "default in mainline Fedora" doesn't preclude the
> > > >         desktop
> > > >            spin from using PackageKit instead of Pirut.
> > > >
> > > > Hmm.  That seems like a really big change to be making from mainline
> > > > in a spin.  I think a good goal for spin changes is to think hard
> > > > about putting in changes that we do want to go down into the OS in
> > > > general.
> > >
> > > Hey, let's not get carried away; this is not a OS-level change, it's, in
> > > effect, simply just another UI frontend for yum, not much different from
> > > pirut/pup, yumex, whatever except that it's designed to solve the
> > > problem in a much nicer way (at least some of us think) both from a
> > > technical point and an user experience point of view. There's no reason
> > > to fear change.
> > >
> >
> > >From a technical point it doesn't solve the problem in a different way
> > at all. I've been helping Richard with scripts to backend packagekit
> > with yum and the scripts are extremely simple. To be clear - some of the
> > user experience items are really just papering over the security
> > questions and hoping no one notices that right now PackageKit is the
> > equivalent of:
> >
> >  yum -y do_whatever_just_be_quiet_about_it.
> 
> I have a *strong* opinion here that it's *never*, *ever* right to ask
> the user a question when installing or removing a package. A question
> is going to be of the form:
> 
>  A) This operation may trash your system [detail that the user doesn't
> understand removed]. Proceed?
> 
>  B) The package that you are installing might be created by an evil
> haxor and do bad things [details that the user doesn't understand
> removed]. Proceed?
> 
> The user has no basis on which to make the decisions, and all you've
> done is created some coverage for yourself when they continue anyways
> and bad things happen. And when I say "the user doesn't understand",
> I'm not being dismissive of some imaginary naive, clueless user. *I*
> almost never understand the details in such cases.
> 
> I do think it's important for something like PackageKit to return
> maximally descriptive error messages to the user; I was quite
> concerned when I saw Richard post that everything had to be turned
> into an error enum in PackageKit so that the translation could be done
> in the front end. I think that's just wrong, and you always want error
> message *strings* to be part of the system, translated at the source
> when applicable.
> 
> [ The above obviously neglects the type of question like "installing
> this package is going to result in installing OpenOffice.org, and
> downloading 300megs of extra packages, taking 3 hours, proceed? Which
> is legitimate to ask the user. I think that type of question, is,
> however, generic enough to be part of a system like PackageKit ]

I'm a little bothered that you're picking and choosing which questions
you think users can answer. I think users can intelligibly understand
statements about gpg keys. The difference here is that I'm assuming that
users are smarter and/or capable of using google to understand what's
going on.

I know this is a cliche - but if you assume your users are stupid, then
you end up with stupid users.

Now, for a lot of yum questions we don't assume the user is stupid, we
assume the user is not present. (ie: unattended cron or daemon-drive
runs). I understand the virtue of making the defaults make sense. I also
understand the virtue of not showing up on bugtraq b/c you auto-import
gpg keys w/o so much as a notice about it.


-sv