Firefox Core Engineering/Get More Data Faster

This effort is establish a shorter path between client crashes and actionable data.

Step 1

1. Land content crash ping (enables new crash ping types)​.​ [end of Q4 2016]
2. Determine how to report on unsymbolicated stack in crash pings (we want to identify what we can answer from the data we collect now, without aggregating and without symbolicating)​.​ [mid-January 2017]
3. Scale/load test the new symbolapi.m.o (we want to know if this will serve its current function AND a future function for release users)​. [mid-January 2017]
4. Determine if we can include frame pointers on release (because it enables future steps). [end of Q4 2016]​

Step 2

1. Land the CrashSender (so we can send a crash ping as soon as possible)​. [mid-January 2017]​
2. Symbolicate crash ping stacks either via batch in data processing or client-side -- depending on the outcome of Step 1.3 and 1.4.​ [TBD]​

Step 3

1. Create "client-side" signatures -- depending on Step 2.2 (whether the stacks in crash pings are symbolicated or not) and Step 1.2 (whether we need to establish these signatures in a data source or in a process on the ping itself).​ [TBD]​
2. Possibly introduce new crash ping types (gpu, etc).​ [TBD]​

Step 4

1. Implement clustering of crashes on the client-side (probably based on signatures) -- depending on Step 3.1. [TBD]

Step 5

1. Allow for correlating between client-side crash clusters and crash-stats-side crash clusters. [TBD]