It's great that many people are weighing in on ideas and comments on this topic!
We'll continue this discussion next week in an open meeting. Please attend if you would like to be involved in helping to come up with ideas on how to solution this problem. *Date: Wednesday, November 4, 2015* *Time: 7:30am PST* *Location: B2G Vidyo Room* *Meeting notes and agenda: https://docs.google.com/document/d/1a4Iopu76TtyVPZkFnmiz-RNPBM_Ajr02kWx1JIyJhm8/edit# <https://docs.google.com/document/d/1a4Iopu76TtyVPZkFnmiz-RNPBM_Ajr02kWx1JIyJhm8/edit#>* Thanks, Candice On Thu, Oct 29, 2015 at 5:05 AM, Wilson Page <[email protected]> wrote: > Instantly propagating updates can sound dreamy, but live code everywhere > can lead to regressions coming from nowhere. > > This approach also puts a massive burden on component reviewers and > contributors. It's much safer to land changes to a component and have apps > *PULL* in the changes. This gives the app owner a chance to spot > regressions, file a bug, remain on the old version and avoid breakage. > > If component updates are *PUSHED *into the apps, regressions will > increase. It is not possible for a component owner or contributor to know > every single instance whereby their component is being used. Regressions > *will* be caused by new patches, our job is to catch them as early as > possible and mitigate the impact these regressions have. > > This problem is why the Semver <http://semver.org/> standard exists and > package managers like NPM have grown so successful. > > > *Our options are:* > A. We force *PUSH* updates into apps and speed up the update process and > introduce more global regressions. > B. We land frequent risk-free incremental patches into a component's > source repo and *PULL* stable versions into Gaia one app at a time (not > to dissimilar from our train-model). > > *How do other people do it?* > > If we look at deployment strategies that have proven to work in > production, they all tend look similar to Option B. Facebook doesn't push > new features onto all of their users at once; they trickle the changes out > to 1%, 2%, 3% of users, until it reaches 100% of users. > > This gives Facebook the opportunity to catch issues early, backout and > fix; without impacting very many users. It would be appealing for them to > be able to ship new changes to everyone in a split second, but this can > hurt their users and end up costing more time than it saves. > > --- > > This clearly need some more discussion, but it's important to note *this > is not a new problem* :) > > *W I L S O N P A G E* > > Front-end Developer > Firefox OS (Gaia) > London Office > > Twitter: @wilsonpage > IRC: wilsonpage > > On Wed, Oct 28, 2015 at 8:56 PM, Justin D'Arcangelo < > [email protected]> wrote: > >> I agree with Sam. But it needs to be trivial for apps to pick up the >> latest changes too. This could be easily solved with Bower. Each app could >> “lock in” to particular versions of the components they’re using. Then to >> get latest, the apps only need to have their version numbers bumped in >> bower.json. >> >> -Justin >> >> >> On Oct 28, 2015, at 4:49 PM, Sam Foster <[email protected]> wrote: >> >> >> >> On Wed, Oct 28, 2015 at 11:52 AM, Patryk Adamczyk <[email protected]> >> wrote: >> >>> >>> So there is also another part to this, and that would to have it sit in >>> a live styleguide. >>> Imagine if the components can be in github and a single change in github >>> would instantly update: >>> + master and every FXOS app >>> + style guide website >>> >>> That would be amazing! >>> >>> It would really echo the ideas of focus and dynamic efficiency. >>> >>> >> I don't think this is either practical or desirable. To have a single >> change cause ripples across all FxOS apps would be really really difficult >> to manage. Talk about strange magic from a distance! Plus we are moving >> away from a monolithic "Gaia app". *I do agree we need a simple opt-in way >> to buy into consistent look and feel and control interactions*. And a way >> to pick up bug fixes or updates from shared components without >> simultaneously breaking unrelated stuff - see Jim's note about font-size >> changes. But I would like to steer us away from the notion of a >> one-size-fits-all UI toolkit. It always ends in tears. Apologies if I'm >> over simplifying or mis-characterizing here, I just want to offer the >> counter-argument. >> >> /Sam >> >> >> >> _______________________________________________ >> dev-fxos mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-fxos >> >> > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > > -- Candice Serran Sr Mgr - FxOS Engineering Pgm Mgmt [email protected] irc: cserran mobile: 303.588.1101
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
