Meta bug to track the efforts of understanding and speeding up the delivery process of system add-ons
As we use system add-on updates as a mechanism to update release end-users instead of doing dot releases, we really should be bumping up the priority of this work. Consider this as an idea: System add-on updates are categorized into types: 1) "high" and 2) "normal" priority. "High" priority system add-on update examples are: 1. We push system add-on update like disabling e10s on RU locales in Fx49 on release channel. This is an update that really is critical and should update itself quickly so as to mitigate end-user crashes. 2. "Websense" related system add-on update. This is another one that is time critical so we can update as many nowebsense users as we can from 47.x to 49.x. "Normal" priority system add-on updates examples are: 1. Pocket updates to address functional bugs. 2. System add-on update that turns e10s off for a small subset of users that see tab spinner longer than 30 secs. The update window for "high" priority pushes is 10-1000x faster (whatever is reasonable from a server load POV) than a "normal" priority push. By default, all system add-on pushes should be "normal" so as not to overload the server/client.
Depends on: go-faster-verification-chain
Whiteboard: [system add-on] → [system add-on] triaged
We have a pretty good idea of the uptake of system add-ons now: https://sql.telemetry.mozilla.org/queries/2654#5575 There is a persistent ~6% of users that don't seem to get the update. These users have Telemetry enabled and also update (incl. auto-update) enabled. The next step is to ship more diagnostic code so we can figure out why this is the case (bug 1307568).
Depends on: 1342982
You need to log in before you can comment on or make changes to this bug.