Disabling whoopsie by default in the 12.04.1 release

Matthew Paul Thomas mpt at canonical.com
Mon Aug 6 13:20:36 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sebastien Bacher wrote on 06/08/12 12:48:
> 
> Le 06/08/2012 13:04, Matthew Paul Thomas a écrit :
>> 
>> - It makes relaunching a crashed application much easier.
> 
> Right, most of the issues we get are with services and not 
> applications though

That isn't true, unless today is a freak exception. Right now, out of
the 50 most common errors, only 17 are from services. The rest are
from applications.

>> - From the next errors.ubuntu.com rollout, it will let release 
>> managers and other contributors see whether Ubuntu Q is more
>> reliable than 12.04.
> 
> I never suggested turning of whoopsie in Q, so we will get metrics
> in Q in any case. We have metrics from precise at release time and
> .1 time, that should be good enough to know where Q stands. I don't
> think lacking a metrics on 12.04.1 post .1 compared to Q is a big
> deal, the LTS shouldn't change much, we want to know where Q stands
> though and we will know since we will keep the system running for
> it.

I think that is mistaken in three ways.

Most importantly, Ubuntu 12.04.1 does not mark the end of updates to
12.04. There will be more SRUs. Hopefully some of those will make
12.04 more reliable. If we're unlucky, others may make it less
reliable. If the latter happens, how will you know?

Second, the kind of people who install 12.04.1 (or buy a computer with
it installed) may have noticably different behavior from the kind of
people who installed 12.04 -- using different applications and
features, and encountering errors at different rates.

And third, there may be time-based problems that people using 12.04
can't have encountered yet (unless their clock was set wrong).

>> With previous versions of Ubuntu, windows would disappear or
>> features would stop working, and people wouldn't know why. The
>> only difference is that now the failure comes with an
>> explanation. It would be best if the failure didn't occur at all,
>> but if it does, it's better for it to be explained than to be
>> mysterious.
> 
> That's again assuming that the errors we received are real bugs
> having an user visible impact, it's true in some cases but I would
> challenge that being the most frequent case, we have been looking
> at those errors for 3 months and most of them are bugs reported
> against services, or happening at session closing, or harmless
> exception uncaught in python programs.

As above, most of them are not against services. And even if they
were, so what? If Bluetooth stops working, for example (a couple of
today's top 50 are in blueman), explaining the error can help someone
understand that a Bluetooth connection failed because of a problem
with Ubuntu, not because they made a mistake. Same if sessioninstaller
fails, or aptdaemon.

>> Turning off error reporting would leave the release team
>> ignorant about whether 12.10 is an improvement on 12.04. But this
>> is not a release-team-specific question. It would make Ubuntu
>> developers in general less productive, and it would make Ubuntu
>> worse for end users.
> 
> The suggestion is to turn if off for 12.04.1, can you explain how
> it prevents us to get metrics on 12.10?

I didn't say it prevents you from getting error reports from 12.10. I
said it prevents you from seeing whether 12.10 is better or worse than
12.04. By "12.04" I include 12.04.1 and any later updates.

>> If you think there are ways the end-user presentation can be
>> improved, I'm happy to take suggestions. Routing around that by
>> asking the release team to disable it altogether is not cool.
> 
> Evan said that work was ongoing on "batching reports to submit
> several together", that will be good. I don't think there is
> magical ways around it otherwise, it's just that 10 bugs a week is
> too much errors dialog popping up.

That is shooting the messenger. Yes, ten errors a week is too many.
Suppressing the error alerts doesn't make that better, it makes it
worse. It's a choice between unreliable, and unreliable + unhelpful.

> The main concern is that only a small fraction of those are user 
> visible issue.

How do you know?

> To take an example a non marginal number of issues happen on
> session closing, they are due to the fact that our desktop session
> management is not really good. That's a known issue, will not be
> fixed in the LTS (the scope of the work is not appropriate for
> stable updates), and is harmless ... still it means lot of users
> get a "system error happened" dialog first thing after next login.
> That has a real cost in user perception, the benefit we get back is
> null though ...
> 
> ...

If they are harmless, why do they need fixing at all? If they really
don't, that error message in particular could be suppressed.

- -- 
mpt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAfxKMACgkQ6PUxNfU6ecrgBwCgic/5+ZzX0R/M7UYJtfRujlq2
57IAn15H1Zf30fX92SrkgP1X6U9MlLbM
=iX97
-----END PGP SIGNATURE-----



More information about the Ubuntu-release mailing list