mozilla / mozilla/bugbot

Don't add the "topcrash" keyword to topcrashers in the first few hours of a release (for bugs with 1-2 total crashes)

Open
#2,623 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area-Crashes area-Noise Reduction
Dominant language
Python
Stars
68
Forks
92
Avg merge
2d 2h
Merged PRs (30d)
16

Description

Somehow, bugbot decided to annotate https://bugzilla.mozilla.org/show_bug.cgi?id=1748675 as a topcrash on beta (I assume specifically Firefox beta 138.0b1) here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1748675#c6

...despite the fact that the bug had only 1 total crash[1] for 138.0b1 at that point, which was this one:
https://crash-stats.mozilla.org/report/index/64241243-4979-4257-8512-c85090250402

I assume this one crash qualified it as a "topcrash" because 138.0b1 had only just been released and maybe we'd only received 10-20 different crash signatures total at that point, all of which are trivially the top 10-20 crashers on beta (if only for that moment).

Rather than mistakenly adding the topcrash keyword to all such bugs on the first day of a beta release (and leaving them labeled as such until someone notices and cleans that up), maybe/probably bugbot should get some additional logic to prevent this -- maybe we need some "cooling off" period where we wait for data to come in for a new release, to be sure we've got enough data to establish useful signals, and only post if crash volume is above a certain threshold? (not sure what threshold makes sense -- it'd still be great to trip alarms if we get hundreds of crashes with a particular signature within hours of a beta going out, but maybe we don't need to rely on bugbot for that.)

[1] There's been one more crash that came in today from what looks like the same Firefox installation, https://crash-stats.mozilla.org/report/index/eeb8f728-a3ca-4714-9e75-954060250401 , but I think that was after bugbot posted its comment)

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the bugbot path that adds the topcrash keyword, then compare its release-age and crash-volume inputs with the linked Bugzilla and crash reports. Done should prevent low-volume labels during the first hours of a release while preserving useful high-volume alerts; the cooling-off period and threshold still need a project decision.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
release, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.