Crash database requirements

[Matthew Paul Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher James Halse Rogers wrote on 09/08/11 06:37:
>
> On Mon, 2011-08-08 at 00:34 -0700, Bryce Harrington wrote:
>...
>> 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 #.
>>
>>  * 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 #.

This one will be tricky without weirding people out ("what is this
'Launchpad' thing and why is it on my computer?"), but I'm sure there's
some way of making it subtle enough.

> To this list I'd add: 
>  * It should be brainlessly easy for users to submit this data.
> Either a single "Yes, submit this crash" confirmation, or a check box
> to automatically submit these crashes.  One of the features that the X
> team really desire out of this sort of database is "how frequent is
> this kind of problem", which requires the widest possible sample
> space.

With my proposed design it's two clicks to submit, then another click to
dismiss the error message. Probably I should simplify it further.

>  * For X and kernel crashes (at least), these reports need to be
> indexable by hardware.  That is, we want to be able to answer both
> "how prevalent are GPU hangs on Intel hardware?" and "on what hardware
> does this GPU hang appear?".  Probably either DMI data or PCIIDs or
> both are needed for this.

I've added all of these to <https://wiki.ubuntu.com/ErrorTracker>. (Not
saying that they're right or wrong, just as a base to work from.)

> 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
>...

Renamed from CrashTracker to ErrorTracker for that reason. :-)

- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk5DqKEACgkQ6PUxNfU6ecpUXgCWO8vUtfc8B+NgN4S0QDCW/WUo
6ACfV6AT4G60kaag1M9UELI2HfNANkM=
=XR2s
-----END PGP SIGNATURE-----