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

Robert Helmer rhelmer at mozilla.com
Sun Sep 27 00:26:03 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.
> 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.
> (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?

I had assumed we were talking about this as a temporary measure, but I
could read it the other way too.. Dave did you mean never doing
restartless, or going forward now and figuring it out later?

I agree that restartless updates is a key reason to implement system add-ons.

Should we delay shipping any system add-ons until that is ready? Is
getting 98% (where can we find the actual number?) of users in 7 days
(instead of 6 weeks) worth it in the meantime?

> 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?

There are benefits to development (don't need to build Firefox to work
on the add-on) and the whole dev+build+deploy pipeline is faster and
should be lower-risk than pushing a full build. It allows teams
working on these add-ons to be more autonomous and not have to sync to
Firefox's release cycle (barring a dependency on a platform change).

Being able to ship updates faster feels like the most compelling reason, though.

> 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

More information about the Gofaster mailing list