User:Nnethercote

From MozillaWiki
Jump to navigation Jump to search

Docs on Bugzilla tags, and examples:


Tasks

XXX: this is a backup of a section from the Uptime wiki, prior to some changes. It'll be removed at some point.

  • Tasks are divided into numerous categories. Each category has one or both of (a) a meta-bug and a table showing the dependent bugs, and (b) a list.
  • Bugs indicate well-defined tasks.
  • List elements indicate (a) tasks that do not yet have a bug filed, (b) tasks that are not well specified or whose benefit is unclear (these often have a trailing '?'), and (c) broad topics best represented by a link to another page (such as a project tracking page).
  • The goal is for every category to end up with a meta-bug and table, and as few list elements as possible.
  • Not every bug that could be included in these tables should be. This is about tracking sizeable pieces of work, rather than enumerating every single related thing that has been done.
  • Some bugs are included in the tables in more than one section, because they are relevant to more than one section.
  • bug 1289677 is a top-level tracking bug that is blocked by all the category-level meta-bugs.

Crash rate tracking

This category is about the tracking of crash rates, using both crash report and telemetry data.

  • Switch from the per-100-ADI metric to the per-1000-hours metric
  • Better dashboards?
  • Track other metrics that may provide insight into how we can improve things?

Pre-release coverage

This category is about the usage and coverage (code, feature, site, hardware, and configuration coverage) of users on pre-release channels, especially Nightly.

  • bug 1280394 [meta] Increase the number of Nightly users [pascal, marcia]
  • Provide test exercises for QA people and keen Nightly users to run regularly [marcia]
  • Improve earlier channel populations to be more representative of the Release population [lonnen?]

Crash report creation

This category is about the creation and contents of raw crash reports as collected on the client.

  • Bugs blocking bug 1289663: [Uptime] Crash report creation

Bugzilla query error

Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1

  • Include JS execution info (stacks? recent JS file/functions we called into? unresolved promises?)
  • Include more URL data (URLS of all open tabs? recent URLs in crashing tab? non-anonymized memory reports?); might require policy/legal approval
  • Don't omit frame pointers?
  • Better identify threads of all platforms, including threadpools

Crash report submission

This category is about increasing the crash report submission rate.

  • Bugs blocking bug 1289671: [Uptime] Crash report submission

Bugzilla query error

Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1

  • Always submit non-sensitive data, and make only the sensitive data part (e.g. minidumps) optional

Crash report handling

This category is about how crash reports are processed, clustered, analyzed, and triaged once they are received by Socorro.

  • Bugs blocking bug 1289676: [Uptime] Crash report handling

Bugzilla query error

Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1

  • Clouseau: Automatically identify changesets that cause regressions [calixte]
  • crash-correlations: Identify correlations for crash signatures [mcastellucio]
  • Provide ability to run custom analysis jobs on crash reports (similar to telemetry analysis jobs)

Note: a cross-variate analysis of FHR data, by Brendan Colloran, which may have useful techniques.

Crash cluster ranking

This category is about how each cluster of crash reports (e.g. those with the same signature) is prioritized, whether by frequency or other means.

  • Take into account crash severity as well as frequency
  • Use Crystal Ball (or other means) to identify how minor crashes on early release channels might become major crashes in later channels

Crash report comprehensibility

This category is about making the contents of crash reports easier to understand, via better presentation and documentation.

  • Bugs blocking bug 1289675: [Uptime] Crash report comprehensibility

Bugzilla query error

Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1

Fuzzing

This category is about fuzzing and similar automatic test exploration tools such as BugHunter.

  • bug 828452 Generate consistent signatures across crash-stats/fuzzing/BugHunter/automated tests Socorro API for generating signatures?
  • bug 1289194 Add LibFuzzer support for testing xul code
  • Better isolate components so they can be fuzzed more easily (like the JS shell)
  • Increase hardware available for fuzzing, for both greater throughput and better hardware configuration coverage
  • Increase fuzzing coverage of non-default options
  • Improve gtests, which are a good starting point for fuzzing
  • Run BugHunter with common antivirus software [tomcat]

Dynamic analysis

This category is about the use of dynamic analysis tools.

Bugzilla query error

Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1

Static analysis

This category is about the use of static analysis tools.

Bugzilla query error

Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1

  • Add more checks to the clang static analysis job [sledru, etc?]

Low-level defect prevention and detection

This category covers low-level changes we can make to the code to prevent entire classes defects, such as using smart pointers and compiler annotations, and also changes we can make to detect defects, such as adding assertions and internal consistency checks.

  • Bugs blocking bug 1289662: [Uptime] Low-level defect prevention and detection

Bugzilla query error

Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1

  • Something like v8's --debug-heap, which checks the GC heap

High-level defect prevention

This category covers high-level changes we can make to the code to avoid entire classes of defects, such as architectural or language changes.

Defective software

This category is about actively tolerating or responding to defective software (OS, drivers).

  • Disable hardware acceleration in the presence of buggy gfx drivers
  • Handle gfx driver resets

Defective hardware

This category is about detecting and tolerating defective hardware: CPUs, memory, disks, etc.

Bugzilla query error

Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1

  • Detect if Firefox is mis-installed (e.g. perform checksums on files) and ask the user to reinstall.

Malware, etc.

This category is about preventing malware, anti-virus, and other third-party code from interfering with Firefox.

  • Windows 10 has better blocking, at least for content processes? (e.g. a DLL whitelist)
  • Reduce export space of xpcom symbols

OOMs

This category is about avoiding and tolerating OOM crashes.

Bugzilla query error

Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1

  • Increase usage of 64-bit Firefox on Windows: Firefox/win64 [cpeterson, etc.]
  • Discuss common OOM cases with partners [harald?]
  • MemShrink
Retrieved from "https://wiki.mozilla.org/index.php?title=User:Nnethercote&oldid=1142606"