On Mon, Aug 20, 2012 at 5:44 AM, Martin Pitt <span dir="ltr"><<a href="mailto:martin.pitt@ubuntu.com" target="_blank">martin.pitt@ubuntu.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I fully agree. However, this only catches one aspect of the problem.<br>
Of course this will be vastly useful for the SRUs that we'll do, but<br>
it will be mostly noise and false expectations for the crashes that we<br>
won't fix in stables (which will be the majority). After 12.04.1 there<br>
won't be a dedicated team any more, and all but the most common<br>
crashes will just stay as they are.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So perhaps one possible compromise would be to only show crashes for<br>
packages in -proposed and -updates? This would limit the reports to<br>
the set of packages that we are still actively working on and would<br>
retain the whoopsie funcionality for pending SRUs, but would silence<br>
it for the vast majority of packages which we don't fix any more in<br>
precise anyway.</blockquote><div><br></div><div>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 <a href="http://errors.ubuntu.com">http://errors.ubuntu.com</a>. 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.</div>
<div><br></div><div>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:</div>
<div><br></div><div><a href="http://irclogs.ubuntu.com/2012/08/16/%23ubuntu-release.html#t15:32">http://irclogs.ubuntu.com/2012/08/16/%23ubuntu-release.html#t15:32</a></div><div><br></div><div>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:</div>
<div><br></div><div><a href="https://wiki.ubuntu.com/ErrorTracker#When_there_are_multiple_simultaneous_errors">https://wiki.ubuntu.com/ErrorTracker#When_there_are_multiple_simultaneous_errors</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> > No, they are normal non technical users who get 5 prompts on login<br>
> > while they didn't start doing anything and when they box is working<br>
> > normally and in a clean state because we collect i.e random shutdown<br>
> > issues and are showing them those after next book.<br>
><br>
> In practice, are the dialogs shown on login after shutdown the main problem?<br>
> If so, there might be a way to mitigate this particular problem without<br>
> hobbling whoopsie entirely.<br>
<br>
</div>Apport 1.26 (since November 2011) made an attempt to ignore crashes<br>
which happen during shutdown (LP #460932), but by nature this is a<br>
rather heuristic and brittle detection. If it still happens too often,<br>
we should definitively make the filter more agressive. This is a<br>
particular class of crashes which are totally not SRU-worthy, and<br>
would normally not have any visual impact at all. Now they just lead<br>
to making session shutdown a lot longer (because it's hanging on the<br>
Apport and core dump I/O), and getting "old crashes" reports at the<br>
next login.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div></div>