Disabling whoopsie by default in the 12.04.1 release

[Evan Dandrea]

Sent using the wrong address. Apologies for the noise.

On Tue, Aug 7, 2012 at 12:23 PM, Sebastien Bacher <seb128 at ubuntu.com> wrote:
> - 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"

It is my understanding that this is precisely why we have a separate
dialog for system errors:

https://wiki.ubuntu.com/ErrorTracker#os-crash

If you're seeing the regular application error dialog for oneconf
despite it not having a desktop file, that's a bug. Please report it.

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

Well, we have two options there as far as I can tell. We can either
disable crash reporting during logout or shutdown, or we can better
handle the presentation of those errors on subsequent login.

The latter is tackled by the multiple simultaneous errors dialog that
Matthew designed. As mentioned in this thread, I've started
implementing this with the hope of getting it landed by the end of the
week:

https://wiki.ubuntu.com/ErrorTracker#When_there_are_multiple_simultaneous_errors

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

Is this happening automatically, or after you click on something?

Fixing Apport to have a privileged DBus backend or to better handle
the password prompts through some other means is definitely on the
radar:

https://bugs.launchpad.net/ubuntu/+source/apport/+bug/871662

> - 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 this is proving to be a problem, I'm sure we can find optimizations
to apport in R. Let me know if it is.

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

Can you elaborate on the discussion that's taken place around this idea?

Could we not modify the session manager to write the graphical login
and logout (started) time to disk? Then, if a crash occurs between the
logout time and login time, we wait to report it until we have a crash
that's after the login time.