Disabling whoopsie by default in the 12.04.1 release

[Sebastien Bacher]

(Trying to shorter the response a bit so the email keep being readeable)

> Sure, but as Matthew points out, these dialogs serve two purposes:
> 1. To let the user know what just happened.
> 2. To let us prioritize work effectively.
>
> They do not make promises about work getting done. If there's software
> that is used by a sufficient number of people to move the needle on
> the front page of http://errors.ubuntu.com but we do not have the
> resources to fix the bugs in it, then we should have conversations
> about dropping that application as a means of reducing the number or
> frequency of errors.
Your reply are mostly around the line of "we should fix issues", which 
is fine but doesn't address the concerns there.

Let me change the angle of my suggestion, and say "we can't keep the LTS 
with that number of error prompts", that's my position.

The possible way out listed so far:
- turn off whoopsie
- increase our involvement on bugs fixing
- drop buggy softwares (not really practical in the LTS, I doubt we can 
drop update-manager or jockey like that)
- other idea you got

We need to pick one and make it happen, i.e we can't say "we should fix 
the issues" and not to do, so I would suggest that we either
- allocate extra resources and focus to fix the issues on the LTS
or
- turn off apport

(I don't think dropping software is practically possible)

If we go for "we allocate extra resources" I would like to see a 
concrete plan for making it happen with an commitment on results (taking 
the daily count by user < 1 for example) and revisiting the decision 
later in the cycle (before LTS .2).

> I don't see how uncaught Python exceptions are harmless. Even if they
> were, codifying this belief of harmlessness in a try, except, pass
> block is a very small patch.
It is, yet many of those sources are unmaintained and that didn't happen 
in the 3 months between 12.04 and 12.04.1, we need to catch up with 
reality and admit that we don't keep up with issues.

> Can you elaborate on what's causing these applications to fail on log
> out? I don't see how logging out by itself invalidates the contents of
> an error report.
>
Usually at some point xorg closes and the dbus session bus goes away 
which leads applications and services which were still running and not 
stopped to hit an error while trying to access dbus or the xserver which 
went away, since usually that happens after the session closed it's 
mostly noise (it wouldn't happen if we had a cgroup or something which 
would ensure all processes are closed when the session goes away but 
that's not the case at the moment)

> Even if
> no one is going to do anything about it, any regression should be at
> least acknowledged and its impact known.
That's a low probability benefit:
- not enough users run proposed to get those issues showing up on the 
report before they move to updates (at which point we already screwed up 
and let a regression in -updates which shouldn't happen)
- they need to rank enough so we notice them on the report
- we would need a way to spot out "new issues", the current "by 
frequency" ranking doesn't tell us what issue started in a recent upload
> Turning whoopsie off for precise leaves users without an explanation
> when any kind of application failure occurs. It means that we cannot
> measure stability of 12.10 against 12.04. It completely leaves us in
> the dark on the state of 12.04 after the .1 release. It's really going
> at the messenger with a hatchet.
That's what we have been doing for 8 years, it's not perfect but it's 
not the end of the world, I guess we could do it for another release?
>> - the evolution of this number?
> I'm not sure what you mean by this. We have a graph on the front page
> that shows the average number of errors per day. In the aforementioned
> RT it's separated out into lines for each Ubuntu version.
The current graph seems to indicate we rank around 1.45 
issue/day/submitter, it only goes back to 07/31/12 though (or it would 
maybe go back further if selecting "year" in the combo was working but 
it seems to timeout, it returns an "An error occurred while trying to 
load the most common problems." after a while on "Loading" here) ... 
what was the number at precise release time. Can we see how much 
progress we did and the look of the curve?
>
> Yes, in the aforementioned RT, you see a graph on the top of the
> problem page with the instance count over time. You also get the
> version-by-version breakdown on the problem page that I mentioned
> above.
Ok, I guess I need to wait on the RT to be closed and to see the update 
to see what's changing exactly but that seems good progresses, thanks 
for that
> I suspect they care more about the errors that happen than the dialogs
> that they get for them.
>
> It's worth noting since you've raised Windows that other mainstream
> operating systems do exactly what we're doing here. When applications
> crash on Windows or OSX, you get a similar dialog.
Right, those don't have issues happening 10 times a week though, I'm 
sure we will get there, but we need to:

- spend more time improving our stability
- stop having so many virtually unmaintained pieces of softwares in our 
default desktop
- improve the system so we don't trigger errors report when not needed 
(the session closing ones showing up on next login for example)

Until we get there I think we should try to not annoy users too mich.
> The users who are talking to you about it. I suspect these are fairly
> technical people who do not need an explanation about what just
> happened when an application disappears - feel free to refute that
> though. My understanding is that our target market is general
> consumers though.
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.

>
> If we completely locked precise down and didn't allow any further
> changes after the .1 release, I'd be happy to reconsider my position.
> But we're not. And letting people continue to upload new versions of
> packages while disabling crash reporting strikes me as reckless.
We have been doing that since Ubuntu exists, sure it's not perfect but 
it has never been so much of an issue, I doubt doing one extra release 
the way we worked for 8 years would mean the end of the world.

Cheers,
Sebastien Bacher