[Go Faster] Do we want system add-ons to update without restarting?

Chris Hofmann chofmann at mozilla.com
Sun Sep 27 00:04:18 UTC 2015


On Sat, Sep 26, 2015 at 3:55 PM, Richard Newman <rnewman at mozilla.com> wrote:

> Do we have any measurements for the distribution of restart times? If 90%
> of our users restart daily, 98% within a week, and we're happy getting 98%
> penetration for an update in seven days, then great — let's not bother
> notifying, and wait for organic restarts.
>


I think there is anacdoal and telemetry data that says users on nightly,
aurrora, and beta channels that shut down less frequently as counted in
days or weeks.  To reach these users "faster" for testing and feedback on
changes in development we would need to silently update and restart, or
notify and run into the same problems and challenges faced with update
fatigue.  So it seems system addons won't help get users new changes faster
on any of these channels.

For users on  release channels its a different story with users typically
running about a 1 hours session per day then shutting down at the end of
that session, then returning a day or two later for the same.

Its probably good to return the rational that's promoting and guiding
system addon work in the PRD to figure out what the requirement might be.

https://docs.google.com/document/d/1H0be9rVfK-molaEa3KPvPLO4hS6iSKs-eHy2HGQwMNY/edit?pli=1

The first rationale says 6 weeks is to long to do updates for new features,
but doesn't say what the update rate should be, or how we might avoid
update fatigue.  So not much guidance there.  Certainly we could increase
the cycle time of updates with either restartless, or at next start.

The second rationale says we have a lot of chemspills.   I've never
understood how this relates to system addon work since 99% of chemspills
are in gecko code and system addons won't help one way or the other.  If
however we assume that system addons could/will be used in responding to
chemspills here is how that might look.   We do chemspills as the result of
severe regression bugs that are causing users to switch to other browsers,
or as response to security problems that are reported and have live
exploits running in the wild.   These are probably the best reason to
support restartless system addons.  If there is severe bug in hello that
constantly disrupts  sessions, or say a security bug in pocket that exposes
browsing history in the clear we would quite likely find it advantageous to
interrupt those  one hour daily session to magically fix a bug that those
users are encountering or vulnerability could be exposed to.  But again
these scenarios seem infrequent at this point, and probably not worth the
engineering cost to build code for these kind of updates.

The third rationale says we need to be able to innovate quickly and respond
to user feedback.  This one also begs the question about how much faster we
need to do these things that we can currently with builds every day on
nightly and additional builds on request on the nightly channel, or  the
cycle rate of any of the other test channels.   Restartless might again
only speed things up by a few days or few hours on the release channels.

The 4th rationale says big releases means an increase in the number of
things that can go wrong.  I'd counter to say that shipping lots of smaller
releases on a parallel update channel also could bring a tendency for
things to go wrong.   If we are trying to reduce errors we would do fewer
things so that might mean the more simplistic model of catching the update
at the next user restart.

So measured against the requirements I'd say restartless addons are not a
requirement for most situations, but I'd also say that requirements and
rational for system addons in general needs more work so it could answer
questions like this and provide better guidance and use cases for what
problems we are actually trying to solve.



> If we require users to restart in order to get fixes and improvements, and
> if we prompt for upgrade, then we're forced to choose between update
> fatigue or shipping less frequently. Even so, we'll get some number of
> users (particularly on Mac, I suspect) not updating for extended periods of
> time.
>
>
yep, we've toyed with trying to do more builds at a faster pace for years,
and generally reached that place where update fatigue discourages updates
and loses total number of users on just about every channel.  Not it seems
system addons might need to consider those same problems,  We could prompt
users to restart, but then it runs the risk of many prompts with many
system addons in play, or we could try to coordinate all the system addon
updates, but all those system are complex and lead us back to update
fatigue.


> (Yup, I still shake my head, restart Firefox, and jump it forward a couple
> of major releases every time I use my partner's laptop.)
>
> Putting on my devil's advocate hat: if we *don't* allow system add-ons
> some way to upgrade without a restart, and if — as I've heard — the system
> add-on approach doesn't really buy us faster turnarounds for chemspills, *is
> it worth doing all of this work*?
>
>
right, if we have good rationale and use cases those should be added to the
PRD..


> If a user has to restart to get new software, what's the advantage versus
> just pushing out a new build of Firefox and using our existing well-tested
> delta-based updater with no nagging to restart?
>
>
I'll also again make the case that we only will get faster by doing fewer
things, or simplifying the code or the decision process by which we create
or manage or distrubute releases.   If we had a set of requirements that
matched well against this overriding goal then we would actually be on a
better course towards going faster.   Each time we look at what we are
doing and say what I'm building actually adds complexity to our code,
testing systems, or release decision making process I'd say we are creating
the conditions for going slower.

Where ever we can, simply and remove to go faster.  Avoid building
duplicate systems that will need to be used, administered, managed, and
maintained.

-chofmann




> On Fri, Sep 25, 2015 at 2:55 PM, Dave Townsend <dtownsend at mozilla.com>
> wrote:
>
>> Support for updating system add-ons has landed in nightly (it isn't
>> turned on yet but that is just a pref flip) but for the moment it still
>> requires a restart to activate the new add-ons.
>>
>> We need to think about whether activating new versions without a runtime
>> is something we want and if so whether we need some UI to allow the user to
>> control when it happens. The problem is that at the moment the update
>> process happens randomly during runtime. Imagine for a second that Firefox
>> Hello is a system add-on and you're in the middle of a call to a friend
>> when the update check finds an updated Firefox Hello. What happens next?
>>
>> For regular Firefox add-ons we just deactivate the old and activate the
>> new. Presumably this would make the Firefox Hello call end abruptly, that's
>> assuming it has been written well enough to do that when deactivated.
>>
>> Other choices include:
>>
>> 1. Leaving updates till after a restart, basically what a user is used to
>> anyway.
>> 2. Giving the user the choice of when to apply the updates, perhaps with
>> some UI explaining what features might be interrupted. I'm not sure there
>> are a lot of benefits to this above a restart.
>> 3. Giving the add-on an API to delay updating. This makes the update code
>> quite complicated and in a bad case might stop updates entirely.
>>
>> I'm leaning towards requiring a restart for now, it is the safest option
>> and means we would need less QA around releasing new system add-ons since
>> you wouldn't need to test updating with Firefox in various different states.
>>
>> _______________________________________________
>> Gofaster mailing list
>> Gofaster at mozilla.org
>> https://mail.mozilla.org/listinfo/gofaster
>>
>>
>
> _______________________________________________
> Gofaster mailing list
> Gofaster at mozilla.org
> https://mail.mozilla.org/listinfo/gofaster
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150926/de32e9f1/attachment-0001.html>


More information about the Gofaster mailing list