CrashKill/Topcrash: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 18: Line 18:
* Bugs that spearhead investigation or fixes across a large collection of crashes
* Bugs that spearhead investigation or fixes across a large collection of crashes
** Judging this needs engineering expertise - if fixing a bug would clean out a number of crashes (with differing signatures) that would be in similar volume to signatures matching other topcrash criteria, that bug itself qualifies for topcrash as well.
** Judging this needs engineering expertise - if fixing a bug would clean out a number of crashes (with differing signatures) that would be in similar volume to signatures matching other topcrash criteria, that bug itself qualifies for topcrash as well.
* Crashes for actions that users are rarely taking, even if they are somewhat out of the usual topcrash ranges
** This needs feeling and expertise as well, thing like that can be e.g. printing crashes in the top 50 on desktop release and similar cases.

Revision as of 21:25, 19 December 2012

The list of topcrash bugs is being kept up to date manually by the stability group by adding or removing the topcrash keyword on open (non-resolved) bugs according to the criteria below and the Top Crashers lists from Mozilla Crash Stats.

Top crash identification criteria

  • Top 20 desktop browser crashes on the latest release (once it is over 10M ADI).
    • The 20-30 mark is where the numbers start to drop below 2000 crashes per week.
    • Also, in the past, many of the crashes in the 20-50 ranges have been repeats of other signatures in the top 50. It's not an exact science here but we think it's important to pick some bar.
    • Anything appearing in the 20-30 range that is marked as a start-up crash is also tagged as a top crash.
  • Top 20 desktop browser crashes on Betas
    • This should be pretty much the same as release. Where we see discrepancies are really around 3rd party issues which are important to call out for blocking candidates.
  • Top 10 desktop browser crashes on Aurora and Nightly, if they happen for enough different installations.
    • This might need some experience and feeling for what issues are important.
  • Top 10 plugin crashes on Beta and Release
    • Hang signatures are pretty generic and non-actionable right now (improvements are being worked on), the crashes in that list need to be looked at more carefully.
  • Top 5 desktop browser crashes on Linux- and Mac-specific list on Beta and Release
    • If there's less than 5 crashes per week on a signature, that bug probably still doesn't qualify - same for crashes happening to only 2 or 3 installations.
    • If volume is very similar to the top 5, other bugs might still be included.
  • Bugs that spearhead investigation or fixes across a large collection of crashes
    • Judging this needs engineering expertise - if fixing a bug would clean out a number of crashes (with differing signatures) that would be in similar volume to signatures matching other topcrash criteria, that bug itself qualifies for topcrash as well.
  • Crashes for actions that users are rarely taking, even if they are somewhat out of the usual topcrash ranges
    • This needs feeling and expertise as well, thing like that can be e.g. printing crashes in the top 50 on desktop release and similar cases.