Hi folks,

On Thursday, August 8, James Willcox, Sebastian Kaspari, and I (Nick
Alexander) met with William Kahn-Greene and Chris Lonnen to discuss using
Socorro/crash-stats to analyse crashes in non-Firefox contexts.  You can
read the mostly complete detailed notes
<https://docs.google.com/document/d/13ZqcDtmedjAykVveOlZSFYP5tWi2i6G5dCzUuHEBY0U/edit#heading=h.aoamwv7wdmuk>
.

The worldview for determining stability

Mozilla has been pushing towards a two pronged aggregate analysis approach:

   1.

   We use “crash pings”, which are a high-volume, low-specificity Telemetry
   signal to understand Firefox stability.
   2.

   We use “crash reports”, which are a low-volume, high-specificity,
   highly-biased Socorro signal to understand specific stability issues.


The critical facts about Socorro, as I understand them:

   -

   Socorro is excellent at processing minidumps
   -

   Socorro has a robust security model for controlling access to PII
   -

   Socorro is not a strong platform for aggregate analysis of crashes


>From this baseline, the discussion split into two contexts:


   1.

   Using Socorro to understand the health of the GeckoView-consuming
   Android App ecosystem (flagship browser for Android, Firefox Reality,
   potential third-party Apps)


   -

      Technically possible right now: need ops to whitelist “application
      name”, but can aggregate minidumps across consuming Apps.
      -

      Strong support for non-Gecko native code crashes (e.g., Firefox
      Reality); symbol server largely stands alone and scales to new uses.
      -

      Minimal support right now, and no long-term plan for investment into
      future support, for first-class support of “managed code” reports (e.g.,
      Java stacktraces or JavaScript stacktraces).
      -

   Using Socorro to understand the health of non-Gecko/non-GeckoView
   Android Apps (Notes, Lockbox for Android).
   -

      Socorro is not a good platform for understanding “managed code”
      reports.
      -

      Considered better to push non-Gecko native code crashes through
      Sentry than to use Socorro: more problems in managed code than in native
      code long term.


The immediate next steps are:

   1.

   William to investigate pushing “bare” minidumps to Socorro to understand
   what, e.g., Firefox Reality actually needs to upload
   2.

   James (snorp) to investigate pushing Gecko minidumps first to Sentry and
   then on to Socorro to understand whether, e.g., Focus (GeckoView) can
   leverage Sentry for managed code crashes while still feeding Gecko
   stability problems into the larger Socorro tool.


Many thanks to William and Lonnen for their ongoing attention to this
effort!  Everybody, please correct errors introduced by your interlocutor.

Yours,

Nick (for James, Sebastian, William, and Lonnen)
_______________________________________________
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct

Reply via email to