Core features shipped as bundled add-ons

[Dietrich Ayala]

In some previous threads and blog posts, we've talked generally about
shipping some features as bundled add-ons. I'd like to dive a bit
deeper into the mechanics of doing this.

Who wants this:

* Product group
* Labs
* Services

Why:

* A/B testing of features
* Region- and/or locale-specific features
* Development workflow independence
* Release cycle independence

Current candidates for this:

* BrowserID
* Share (F1)
* OpenWebApps
* Any others?

We've been mapping out the process for this with BrowserID, and so far
it looks like this:

* BrowserID is developed however/wherever by it's team
* On a project branch, the add-on source code is landed in
/browser/app/profile/extensions/{add-on-id}
* The add-on is packaged with the browser during the build process
(eg: http://j.mp/t9sSXP)
* The project owners periodically drop new versions into the project
branch, to test quality/performance
* When ready, the project moves off project branch into the mainline

Technical questions Mossop brought up from the Test Pilot experience,
that we need to answer:

* Would users be able to uninstall?
* What would happen when the user upgraded to a build that didn't ship
the add-on?
* Could Test Pilot update from AMO?

There are other questions, such as:

* How best to do L10n - Test Pilot keeps it's strings in the core, IIRC
* If/how to integrate the add-on's unit tests into our continuous
integration system
* Christian & release team, any release-specific issues come to mind?

Gavin mentioned that some process questions related to quality, review
and landing requirements occurred during the Test Pilot integration.
The requirements should be the same as for any code that ships with
the browser - the problem was that not everyone involved had run that
gauntlet. We need to over-communicate early and often what those
requirements are to everyone involved. Just because some code is
developed on a daily-basis in a project branch or external repository,
the responsibilities, expectations and requirements are the same as
for any code that lands on Mozilla-central.

[Lawrence Mandel]

> From: "Dietrich Ayala" <auto...@gmail.com>
> To: "mozilla. dev. planning group" <dev-pl...@lists.mozilla.org>
> Sent: Thursday, November 10, 2011 6:37:56 PM

>
> Technical questions Mossop brought up from the Test Pilot experience,
> that we need to answer:
>
> * Would users be able to uninstall?
> * What would happen when the user upgraded to a build that didn't ship
> the add-on?
> * Could Test Pilot update from AMO?

I like the direction.

Too many add-ons installed by default may cause confusion as users won't easily be able to tell which add-ons they've installed themselves. Has any thought been given to differentiating between add-ons that come preinstalled with Firefox and add-ons that the user installed manually? A similar issue (and one possible solution) can be seen with system installed apps on Android.

Lawrence

[Mook]

On 11/10/2011 3:37 PM, Dietrich Ayala wrote:
> In some previous threads and blog posts, we've talked generally about
> shipping some features as bundled add-ons. I'd like to dive a bit
> deeper into the mechanics of doing this.

Yay! For what it's worth, Songbird did this (and had ugly hacks around
the (old) extension manager and updater to support some related tasks),
and it seemed fine. Didn't have many issues around QAing the
combinations either, or people not having addons. But in the Songbird
case the addons were more focused in pre-determined extension points and
anything that couldn't be hooked by (third-party) extensions was shipped
with the app instead; not sure how this will go with the way Firefox UI
tends to have heavy inter-dependencies. There was also something to
suggest addons to download on first run, as well; not sure that was the
best UI, though. (It made sense in context, since if you have no music
imported the app wasn't really useful.)

Komodo ships some addons with the app too, but in that case the app can
break (as in, important functionality missing) if you disable the wrong
thing. At least it should be alive enough for you to get to the addon
manager and turn it back on... (Luckily, that's designed for a more
technical audience.)

FWIW, in both of these cases there was no separate engineering team for
just the addon bits; they were both (smallish) engineering teams that
covered the whole app.

Please feel free to ping me if my experience might be helpful. Or not,
if, umm, not. ;)

--
Mook

Hoping this helps

[Dietrich Ayala]

Thanks Mook! That's great information - I'd forgotten that Songbird took this approach early on.

How did Songbird handle things like l10n and unit tests for the add-ons?

[Mook]

On 11/12/2011 9:29 AM, Dietrich Ayala wrote:
> Thanks Mook! That's great information - I'd forgotten that Songbird took this approach early on.
>
> How did Songbird handle things like l10n and unit tests for the add-ons?

The addons were in-tree, and their locales were checking in next to the
en-US bits (e.g.
http://src.songbirdnest.com/xref/trunk/extensions/mashTape/chrome/locale/en-GB/mashtape.properties);
they get shipped inside the XPI (see
http://addons.songbirdnest.com/addon/73/versions for an example).
They're not part of the l10n webapp
(http://translate.songbirdnest.com/languages/en-GB?q=mashtape). I
suspect you guys will take an improved approach here.

The units tests are MIA; this was, sadly, a problem for the whole app,
not just the addons. Since the addons were built as part of the app
build, though, had any UI testing existed they'd just get tested along
with the app. (This would unfortunately not cover the case when it was
user-disabled, of course.) UI testing was more manual at Songbird, thus
variations are easier to have (but harder to track).

Sorry, it sounds like my answers are just all giant holes :|

--
Mook

[Christian Legnitto]

FWIW, we might be wading into this area a bit with the add-on hotfix feature:

https://wiki.mozilla.org/Features/Desktop/Add-on_hotfix

The feature is dealing with functionality changes *after* the fact, but I would imagine a fair amount of the lessons will apply to features shipping as add-ons by default.

Thanks,
Christian

On Nov 12, 2011, at 9:29 AM, Dietrich Ayala wrote:

> Thanks Mook! That's great information - I'd forgotten that Songbird took this approach early on.
>
> How did Songbird handle things like l10n and unit tests for the add-ons?

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

[Robert Kaiser]

Dietrich Ayala schrieb:

> In some previous threads and blog posts, we've talked generally about
> shipping some features as bundled add-ons. I'd like to dive a bit
> deeper into the mechanics of doing this.

Just FYI, SeaMonkey has been doing this forever with DOM inspector,
venkman and ChatZilla.

Robert Kaiser


--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)