Crash database requirements (was: The need for apport hooks (was: Re: SRUs for typo fixes in descriptions))

[Bryce Harrington]

On Mon, Aug 08, 2011 at 12:18:51AM -0700, Bryce Harrington wrote:
> > 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.

Here's a start...

 * A collection of files are gathered client-side and inserted into the
   crash database record.

 * Processed versions of files (i.e. retracer output) can be added
   subsequently.

 * Some files must be kept private (i.e. core dumps)

 * Traces from multiple crash reports are algorithmically compared to
   find exact-dupes and likely-dupes.

 * Crash reports can be grouped by package, by distro release, or by both.

 * Statistics are generated to show number of [exact|exact+likely] dupes
   for each type of crash.  Statistics can be provided by package, by
   distro release, by date range, or a combination.

 * Bug report(s) can be associated with a given set of crashes.

 * The user should have some way to check back on the status of their
   crash report; e.g. have some report ID they can look at to see
   statistics and/or any associated bug #.

Bryce