Thanks for the insight Sam! IMO minimising friction is critical to usage and contribution. For this reason I believe it's a worthwhile payoff to add a little friction on our side (versioning, installing etc), in order to lower the barrier to entry and streamline the third-party contribution pathway.
If third-parties like our components and find them familiar and easy to use; they'll use them. If they depend our components, it's in their interest to improve them and fix bugs. As Gaia contribution continues to wane, I'm hopeful we can use gaia-components as a friendly approachable on-ramp to FirefoxOS contribution. *W I L S O N P A G E* Front-end Developer Firefox OS (Gaia) London Office Twitter: @wilsonpage IRC: wilsonpage On Thu, Oct 29, 2015 at 7:11 PM, Sam Giles <sgi...@mozilla.com> wrote: > At the Financial Times we were solving these sorts of problems with what > we branded Origami components - see http://registry.origami.ft.com. > > Disclaimer: I used to work on this. > > Each component was in it's own repository, releases were made on an ad-hoc > basis - as and when needed, breaking and major changes would necessitate a > major version change etc. Product and component developers - and there > were a lot of them - would then pull in a component at build time (we even > supported at runtime with https://build.origami.ft.com!) locked to a > particular major version - we used semver religiously. Bower was used as a > dependency manager - admittedly with varying degrees of success at first. > > As you can see, there are a lot of individual components in different > repositories - we had only minor issues with this, but we solved a lot with > tooling and process: > http://origami.ft.com/docs/component-spec/modules/#managing-new-releases. > > Tooling when using web components, from our experience there, is *so* > important - the 'Component Info' section and the data found there was > particularly useful when managing releases and figuring out dependents and > dependencies: > http://registry.origami.ft.com/components/o-typography@2.0.3#section-info > for example. > > Tooling also helps with the discovery problem: registry.origami.ft.com - > which becomes a kind of living style guide. > > This worked at scale - some background can be found here if you're > interested: http://triblondon.github.io/talk-components-origami/#/1 > > I'm actually for a single repository of components, but *only* if we can > make it easy for the community to pull in and use components in their apps > as dependencies with minimum friction. > > Sam > > > > > On Thu, Oct 29, 2015 at 6:20 PM, Augustin Trancart < > augustin.tranc...@phoxygen.com> wrote: > >> >> On 29/10/2015 18:03, Fabrice Desré wrote: >> >>> It's interesting that you use Facebook as an example. There was a talk >>> recently from one of their release manager >>> (https://air.mozilla.org/release-engineering-at-facebook/) and some take >>> away are: >>> - they use a (huge) mercurial monorepo (like Google does). Everything >>> needs to always work on tip basically. For sure being a closed >>> organisation may make that easier, but FxOS/gaia could be seen as a >>> closed organisation with not much harm I think. >>> >> >> My 2 cents: I'm far from advocating a unique repo, but having too many >> repos with dependencies between them is not great either. >> I personally found working on gaia-icons quite painful (as a reference: >> bug 1209961 [1]. The number of PR it has is ... meaningful). It's difficult >> to make contributor stick around if they need to update X repos before even >> considering pushing their changes to gaia. >> >> So I would propose to have only one repo for all web components of gaia. >> This way, it would be much easier to make change to a wc which other wc >> depend on. And we could still tag stable versions and pull them gaia-side. >> Things stay manageable, even if every app has an explicit dependency on >> this shared repo. >> >> Another drawbacks I see of having a lot of separate repos for shared is >> that their discovery is made more difficult. They risk becoming underused. >> gaia-icons is a good example again: I don't know the whole story behind it, >> but I guess the idea was to provide a set of common icons for FxOS. A lot >> of apps have actually their own svg or png that luckily often look more or >> less the same (I'm speaking about back, forward, send, edit-mode, close, >> attach icons, and many others). >> >> TL;DR Basically, let's keep the dependency tree as flat and simple as >> possible to avoid headache. >> >> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1209961) >> >> Augustin Trancart >> Phoxygen >> >> >> >> >> - no manual QA, everything relies on CI. They ship their sites twice a >>> day, their mobile apps weekly. >>> - all employees are forced to use the beta version. So when they stage >>> changes to users, it's not for quality/bug testing reasons but mostly to >>> test product ideas (ie. a/b testing). >>> - our build & CI systems are from the last glaciation compared to theirs. >>> >>> Fabrice >>> >>> On 10/29/2015 05:05 AM, Wilson Page 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 >>>> <jdarcang...@mozilla.com <mailto:jdarcang...@mozilla.com>> 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 <sfos...@mozilla.com >>>>> <mailto:sfos...@mozilla.com>> wrote: >>>>> >>>>> >>>>> >>>>> On Wed, Oct 28, 2015 at 11:52 AM, Patryk Adamczyk >>>>> <padamc...@mozilla.com <mailto:padamc...@mozilla.com>> 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 >>>> dev-fxos@lists.mozilla.org <mailto:dev-fxos@lists.mozilla.org> >>>> https://lists.mozilla.org/listinfo/dev-fxos >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> dev-fxos mailing list >>>> dev-fxos@lists.mozilla.org >>>> https://lists.mozilla.org/listinfo/dev-fxos >>>> >>>> >>> >> _______________________________________________ >> dev-fxos mailing list >> dev-fxos@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-fxos >> > > > _______________________________________________ > dev-fxos mailing list > dev-fxos@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-fxos > >
_______________________________________________ dev-fxos mailing list dev-fxos@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-fxos
