ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

On Sun, 2014-06-08 at 00:23 +0100, Alan Pope wrote:

> > That'll collect the additional apport data and put them into errors for
> > grouping. I imagine that most devs are checking errors for stack traces of
> > their packages already, and that way we can see if they happen on specific
> > devices/architectures/etc.
> 
> I wasn't sure if devs actually look at the uploaded crash reports. Is
> your imagination matched with reality? Can I expect that developers of
> foo will look for crashdumps for foo? Is that reasonable? (I feel
> there's a common {mis}conception that crashdumps disappear into the
> aether and are never looked at, which would be good to dispel).



Well, I can't speak for everyone, but I do :-) That might be because
most of the stuff that I work on is already converged, so the desktop
and other platform results are more significant. People who work on
projects that are only currently shipping on the Devices images might
not be used to looking there because the sample size is too small to
make them show up with any frequency. There's also some history here the
apport-noui job was broken, so phones weren't uploading crashes. But, I
think in general that should be our solution as we start to get more and
more devices in the market. If I can see a major crasher, then I notice
that one of those comes from a test suite we have, I know how to
recreate that crasher and verify it is fixed. That's immensely powerful.


> > There's currently no tool to add a custom field on the crash reports like
> > "AlanTesting: Staring app" or similar. But I it shouldn't be too hard to add
> > at the top of the crash files with a small script. Then we should be able to
> > search for them by that key I believe (cc'd Evan to check that)
> >
> 
> I'm not looking for special treatment, I'm just interested in making
> sure developers look at the crash reports, whoever files them.


I wouldn't give you special treatment :-)

I'm more looking to mark the crashes that come from tests that we can
recreate so that we know the process that went into making it crash. If
there's a messaging menu crash that is caused by a test of the telephony
app that's valuable information in debugging it. May not help all the
time, but it seems that we should avoid loosing that information if we
have it.

Ted

Attachment: signature.asc
Description: This is a digitally signed message part