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 <[email protected] <mailto:[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. -JustinOn Oct 28, 2015, at 4:49 PM, Sam Foster <[email protected] <mailto:[email protected]>> wrote: On Wed, Oct 28, 2015 at 11:52 AM, Patryk Adamczyk <[email protected] <mailto:[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] <mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-fxos _______________________________________________ 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
