1,478 bytes added,
19:00, 19 December 2016 This effort is establish a shorter path between client crashes and actionable data.
== Step 1==
# Land content crash ping (enables new crash ping types). [end of Q4 2016]
# 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]
# 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]
# Determine if we can include frame pointers on release (because it enables future steps). [end of Q4 2016]
== Step 2==
# Land the CrashSender (so we can send a crash ping as soon as possible). [mid-January 2017]
# 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==
# 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]
# Possibly introduce new crash ping types (gpu, etc). [TBD]
==Step 4==
# Implement clustering of crashes on the client-side (probably based on signatures) -- depending on Step 3.1. [TBD]
==Step 5==
# Allow for correlating between client-side crash clusters and crash-stats-side crash clusters. [TBD]