Re: Crash database requirements (was: The need for apport hooks (was: Re: SRUs for typo fixes in descriptions))
It might be good to look at the Android equivalent of this too: http://android-developers.blogspot.com/2010/05/google-feedback-for-android.html Martin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Crash database requirements (was: The need for apport hooks (was: Re: SRUs for typo fixes in descriptions))
On Tue, Aug 9, 2011 at 5:37 PM, Christopher James Halse Rogers r...@ubuntu.com wrote: While we're using the terminology crash report, I want to ensure that there's a sufficiently general understanding of what this means. I think we'd want this to cover at least: * Actual C-style crashes, with core. * Unhandled exceptions, such as you'd get from Python et al * Kernel oops and panics * Intel GPU dump output * dmesg Xorg.0.log, triggered by GPU hangs All of those fit what I've been talking about :) - I'd extend the list with: * Nonfatal but significant issues (e.g. in LP a page that is slower than N seconds is logged with full data gathering but does not show an error to the user.) A desktop example might be requested X extensions that a driver doesn't support well (giving data to inform development decisions such as optimisation efforts). -Rob -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Crash database requirements (was: The need for apport hooks (was: Re: SRUs for typo fixes in descriptions))
On Mon, Aug 08, 2011 at 04:25:30PM +1000, Christopher James Halse Rogers wrote: On Sun, 2011-08-07 at 22:46 -0700, Bryce Harrington wrote: On Mon, Aug 08, 2011 a 07:17:52AM +0200, Rick Spencer wrote: On Sat, 2011-08-06 at 15:46 -0700, Bryce Harrington wrote: side comment I think we are doing it wrong: we should collect crashes on all supported releases. /side comment I agree. As designed, apport files a new bug report for each crash, which can quickly lead to excessive numbers of dupe bug reports (there are ways of making apport auto-dupe, but this takes effort to set up and isn't always 100% reliable). This can quickly become unmanageable especially for packages that lack someone to keep an eye on the bug reports. In any case, these types of reports post-release are most useful in aggregate rather than as individual bug reports. If they were filed in some ultra simple crash database (with no signup required of the user) we could get most of the value without incurring a lot of extra bug labor. Has this very thing not been proposed? We should discuss doing this for 12.04. It's been propsed and discussed previously, like ScottK mentioned. The issue has been finding someone with time to work on it. I know it's been proposed and discussed previously, and I believe Robert Collins both wants something similar for Launchpad and has done some work towards making it happen. Yes, there's an open bug report against LP for it I ran across at one point. I don't know if we've actually written down what we want out of a crash database, though. Do we have a requirements document for one? If the Launchpad team wanted to devote some time to adding a crash database do they know what we want out of such a beast? I agree, that seems like an important first step. At this point it's unclear whether Launchpad's needs overlap with ours or if they're highly divergent. Is there a LEP for a crash database? If not, perhaps we could gather requirements in this thread and then write one? There was a LEP started several years ago but it was abandoned and the spec is considered obsolete by the LP folks. There are no active LEPs that I know of. Bryce -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Crash database requirements (was: The need for apport hooks (was: Re: SRUs for typo fixes in descriptions))
On Mon, Aug 8, 2011 at 6:25 PM, Christopher James Halse Rogers r...@ubuntu.com wrote: I know it's been proposed and discussed previously, and I believe Robert Collins both wants something similar for Launchpad and has done some work towards making it happen. I have a draft implementation of a core db server intended for use with LP's own crash reporting requirements, and hopefully scalable enough to handle a high volume of reports (e.g. 1M/day). I don't know if we've actually written down what we want out of a crash database, though. Do we have a requirements document for one? If the Launchpad team wanted to devote some time to adding a crash database do they know what we want out of such a beast? The LP team doesn't *currently* have working on this in our short term plans; if the stakeholders wanted to negotiate queue jumping, we could put a squad on it at the end of the next(ish) project, or some folk may do something in scratch time (like my experiment with cassandra has been). Is there a LEP for a crash database? If not, perhaps we could gather requirements in this thread and then write one? Yes, there are two in active discussion I believe: There is this: https://dev.launchpad.net/LEP/OopsDisplay (ignore the name, which could be better). And the Ubuntu folk the dublin sprint are putting some distro side needs together - https://wiki.ubuntu.com/CrashTracker - which is on my TODO list to provide some thoughts on the server design side. As part of the Launchpad SOA process we'll be splitting out various crash report tools that are currently part of the LP codebase itself - into small reusable python modules. I'd be delighted if they are generic enough to fit in with Ubuntu's needs here - ideally through migrating parts of apport into using the core facilities [we looked at using apport for LP's needs, but the bits we need are different enough that the engineers assessing it decided not to]. -Rob -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
