Disabling whoopsie by default in the 12.04.1 release

Evan Dandrea ev at ubuntu.com
Mon Aug 20 09:19:33 UTC 2012


On Mon, Aug 20, 2012 at 5:44 AM, Martin Pitt <martin.pitt at ubuntu.com> wrote:

> I fully agree. However, this only catches one aspect of the problem.
> Of course this will be vastly useful for the SRUs that we'll do, but
> it will be mostly noise and false expectations for the crashes that we
> won't fix in stables (which will be the majority). After 12.04.1 there
> won't be a dedicated team any more, and all but the most common
> crashes will just stay as they are.
>

I think the less people we have working on a point release, the more
valuable accurate data becomes. With such small numbers attacking the
problem, I would hope the release team wants them picking from the top of a
severity-ordered list, rather than what they *think* is the most pressing.

So perhaps one possible compromise would be to only show crashes for
> packages in -proposed and -updates? This would limit the reports to
> the set of packages that we are still actively working on and would
> retain the whoopsie funcionality for pending SRUs, but would silence
> it for the vast majority of packages which we don't fix any more in
> precise anyway.


I think this assumes that only packages we've just updated meet the
threshold for further fixes. Each point release will bring large numbers of
new users to the operating system, who's behavior may differ greatly from
the existing people feeding crashes into http://errors.ubuntu.com. There
will likely be high-instance problems for packages that we did not issue an
update for, that we were not aware of prior to the release of 12.04.1, just
as this occurred for the 12.04 release.

I do appreciate the effort to find a compromise though. We did ultimately
decide to keep error reporting on for 12.04.1, as the average number of
errors per week met the requirement set forth by the desktop team:

http://irclogs.ubuntu.com/2012/08/16/%23ubuntu-release.html#t15:32

Of course, we should keep discussing how we can improve the situation with
actionable items. I'm working hard to get the multiple error reports in a
single dialog work done for 12.04.2 and 12.10:

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

> > No, they are normal non technical users who get 5 prompts on login
> > > while they didn't start doing anything and when they box is working
> > > normally and in a clean state because we collect i.e random shutdown
> > > issues and are showing them those after next book.
> >
> > In practice, are the dialogs shown on login after shutdown the main
> problem?
> > If so, there might be a way to mitigate this particular problem without
> > hobbling whoopsie entirely.
>
> Apport 1.26 (since November 2011) made an attempt to ignore crashes
> which happen during shutdown (LP #460932), but by nature this is a
> rather heuristic and brittle detection. If it still happens too often,
> we should definitively make the filter more agressive. This is a
> particular class of crashes which are totally not SRU-worthy, and
> would normally not have any visual impact at all. Now they just lead
> to making session shutdown a lot longer (because it's hanging on the
> Apport and core dump I/O), and getting "old crashes" reports at the
> next login.
>

I still don't understand why we're not fixing these applications. If you
handle the exception of an object on the bus going away, you'll catch more
than just errors on shutdown.

I worry this is just going to let us ignore the problem. It will mean
discarding potentially important errors that happen to occur at shutdown or
only occur at shutdown.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20120820/e684ad0f/attachment-0001.html>


More information about the Ubuntu-release mailing list