Disabling whoopsie by default in the 12.04.1 release

Sebastien Bacher seb128 at ubuntu.com
Tue Aug 7 11:23:58 UTC 2012


Le 07/08/2012 11:47, Matthew Paul Thomas a écrit :

>
> But optimizing purely for the number of error prompts is the wrong
> goal. The situations we're discussing are situations where *something
> has already gone wrong*. We then have a choice between explaining what
> went wrong, or leaving it a mystery.
I disagree with that, it's half of the story.

The other side of the coin is:

- dialogs that appears out of nowhere while working and where you didn't 
get an issue (let's make an example "oneconf regular index update failed 
in background"), the dialog doesn't guide the user or explain anything, 
it just creates confusion "what is oneconf", "is the fact that it failed 
an issue", "what should I do", "what does it mean for my system"

- dialogs that appears after login but don't concern the current 
session, those don't explain anything or are not logically connected to 
the issue which happened in the previous session or at shutdown

- password prompts locking your screen because an error happened to a 
service running with another user than yours

I would argue that those are not helping the user, quite the contrary
>
> Now, you propose that so few of the crashes in Ubuntu 12.04.1 need to
> be explained, that *none* of them should be. But you haven't provided
> any data to support this. The claim that most crashes are in services
> isn't supported by the evidence. (Of the most common reported errors,
> yesterday 17/50 were; today only 7/50 were.)

First qualifying my position as "none should be explained" is 
misleading, I would really much to have real user facing issues 
explained in a way which makes sense to users, I challenge that our 
current system does that though

I don't have hard datas, but you don't have either...does anyone has 
ideas how to get better numbers?

What I can say from those numbers is that we:
- don't know how many got displayed is a reasonable timeframe to the 
user to have a meaningful connexion to the issue (opposed to e.g next login)
- don't know how many have an user visible impact
- we don't know if users make the connection between the issue and those 
dialogs (what if gedit hits an issue when closing it, then apport takes 
a minute to process the datas and then you get a dialog ... by the time 
you moved to something else and wonder wth you get a gedit error when 
you stopped using it for a minute)


> If we can isolate particular classes of error that we can be confident
> don't need explaining, then great! Let's not show an error prompt for
> those. (We could batch up the error reports, and send them next time
> an error occurs that does need to be explained.) For example, perhaps
> you could describe how to identify errors that happened at logout or
> shutdown.
>
That would be a good step indeed, we discussed that in the past but 
that's not easy to do unfortunately and we didn't see so much progress 
on that front so far but if somebody has good ideas how to do it in an 
reliable way, or time to work on that, please let us know

Cheers,
Sebastien Bacher



More information about the Ubuntu-release mailing list