462235 - unconditionally process (not throttle) crash reports that have a comment

Status: RESOLVED FIXED

(Socorro :: General, task)

Description

[Wayne Mery (:wsmwk)]

unconditionally process (not throttle) crash reports that have a comment, regardless of version or build.

For the average crash, or topcrashes anyway, comments are typically not critical to diagnosis. However, I suggest there are many cases where where the stack is not enough comment can be essential to diagnosis or matching to a bug. To name a few:
* stack varies or top of stack is useless
* rare crashes, edge cases, random crashes
* where steps to reproduce are required
* crashes with same top of stack represent multiple bugs, i.e. multiple triggers

Yesterday I had sampled thunderbird trunk top crashes, 2% had comments (10 of ~200 crashes). I doubt that can be extrapolated to branch release crashes (I suspect the % is much lower). The point though, is we get very few reports with comments describing the circumstances of a crash - we should make the best possible use of all such reports.

Comment 1

[K Lars Lohn [:lars] [:klohn]]

This is certainly possible with the existing throttling code: it would just require a configuration change.

However, because the comments field is not yet passed through to the database, implementation of this configuration change would have to wait for 444106 to be deployed.

Do we have a procedure for determining consensus on throttling configuration?  The more throttling conditions that we have in the collector, the slower the collector will get.  I'm not sure how many conditions it would take to negatively affect performance.

Comment 2

[(not currently active) Ted Mielczarek]

(In reply to comment #1)
> However, because the comments field is not yet passed through to the database,
> implementation of this configuration change would have to wait for 444106 to be
> deployed.

I think you're thinking of the "Notes" field. We currently store and display Comments.

> Do we have a procedure for determining consensus on throttling configuration? 
> The more throttling conditions that we have in the collector, the slower the
> collector will get.  I'm not sure how many conditions it would take to
> negatively affect performance.

I'd say play it by ear. If it looks like we're getting too complicated we can reassess.

Comment 4

[Wayne Mery (:wsmwk)]

hmm, I thought we had done this - so much for memory. 

And i was about to say we don't need this for thunderbird 3 because our non-release crashes aren't being throttled.  But again sucky memory, bug isn't fixed: Bug 463277   Enable 100% sampling of Thunderbird crashes  (perhaps Seamonkey wants the same?)

The issue for thunderbird is we really can use all crashes, and all comments, because:
a) our crash counts are relatively low because of our small tester base
b) comment rate is in the range of 1 per 100 or 200 crashes - which (I'll say it again) sucks

Plea - It will be super to have this and Bug 463277 in the next 2 weeks so we can catch & fix more crashes during our final beta period. Please know that everyone associated with Soccoro has been very helpful, and it's really shaping up. But these two additions would really help Thunderbird QA.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Lars, what's the status here?

Comment 6

[Jesse Ruderman]

I think this got fixed as part of the push in bug 504627.

Comment 7

[K Lars Lohn [:lars] [:klohn]]

yes, this was implemented and pushed to production.