[Go Faster] Do we want system add-ons to update without restarting?
lthomson at mozilla.com
Mon Sep 28 13:53:29 UTC 2015
Excuse my late appearance in the thread: I am anaphylactically
allergic to long mailing list arguments.
On Sat, Sep 26, 2015 at 8:26 PM, Robert Helmer <rhelmer at mozilla.com> wrote:
> On Sat, Sep 26, 2015 at 3:55 PM, Richard Newman <rnewman at mozilla.com> wrote:
>> 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.
Restartless updates for system add-ons are generally a Good Thing in
my view. They help fight update fatigue by doing updates in a more
transparent way; we don't have to wait for the user to restart which
as noted could be an unspecified period of time; and there's an almost
magical quality to them.
However, I don't feel like we need all system add-ons or all updates
to be restartless. It could be a property of a particular add-on
(always restartless/never restartless) or particular updates could be
marked as "needs restart".
We have other options that I see, also:
- Notify the user of an update that has landed and requires a restart.
This could be done for all updates (not preferred) or for critical
updates (security or stability). We currently tell users they have a
new version of Fx downloaded for train updates, so they are used to,
but anecdotally irritated by this. I also know that Spotify do
continuous deployment requiring restart, and that, also anecdotally
causes update fatigue, but doesn't hold them back at all;
- Notify the user daily that some updates have been downloaded and
offer restart to apply them (bundling updates);
- Force a restart during an idle period, daily (or on whatever period)
- this could also be something we offer to the user, in the interest
of preserving user sovereignty. "Restart nightly to apply updates?" or
What I'd like to do here is engage with UX/User research. We may be
able to get some actual data on our users which can help us decide.
That shouldn't block us from moving forward on the back end: we don't
have to solve this first, or solve for the optimal case first. We have
a thing that will work (non-restartless for now) and can build on it
once we know more.
> 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?
No, we shouldn't delay an MVP until we know everything, or we will never ship.
I'll see what we can get in terms of data from the metrics pipeline.
>> 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).
What Rob said, here.
> Being able to ship updates faster feels like the most compelling reason, though.
There's plenty of evidence that this is virtue enough to push ahead.
Shorter cycle times lead to better quality and better agility to
respond to user feedback. There are tons and tons of case studies,
because so many companies have moved this way. We are dinosaurs in
This to me is the key reason for this entire project, and the reason
we have wide and enthusiastic support, including from cbeard and SCVP.
>> On Fri, Sep 25, 2015 at 2:55 PM, Dave Townsend <dtownsend at mozilla.com>
>>> 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
>>> 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
>> Gofaster mailing list
>> Gofaster at mozilla.org
> Gofaster mailing list
> Gofaster at mozilla.org
More information about the Gofaster