On Fri, Nov 20, 2015, at 06:03 PM, Justin D'Arcangelo wrote: > If the app owners cannot agree to follow the architecture that the NGA > group has spent many months defining and validating, then I really > don’t know how we’ll ever scale FxOS up to meet our future needs.
Disclaimer: I understand this comment was made in a back-and-forth about engineering issues which we all care very deeply about and so may not be exactly what you intended to say, but I think the underlying point is still worth addressing. I'd like to reiterate :djf's comment that "Mozilla engineers understand modularity and its benefits." Specifically, I worry that there's an impression that the state of the tree at the transition to v2.5 was entirely intentional or somehow due to a lack of understanding of good software engineering practices. The general time-pressure, emergent branching, repeated stabilization- focused intervals with strict uplift approval, and externally-imposed features led to a sustained period where there was limited time for cleanup, involving a lot of duct-tape engineering. And I worry that this has led to the impression that engineers outside of the NGA group somehow can't be trusted to make their own engineering decisions. This matters because as Ari made the point at the recent FxOS all hands, "end user value" is of vital importance, and given our limited resources, we are frequently making decisions between: * Making user-visible enhancements * Paying down technical debt * Attempting to drive the platform forward by being experimental guinea pigs * Attempting to standardize across all FxOS apps * Attempt to be more webby in some abstract sense. Concerns in particular can arise where it can seem like "NGA for the sake of NGA" that does not address perceived problems is creating busywork. Or where being a platform guinea pig has known risks that are at odds with having a usable product[1] given the continued limited bandwidth of the platform team. A point being made in multiple places is that most of the NGA efforts that were beneficial aren't so much a result of specific NGA implementation choices being the cure for everything, but simply that NGA is also built-on sound engineering principles of modularity, encapsulation, etc. and that in v2.5 we've had time to pay down technical debt. I think it makes sense to say: "Hey, engineers, we trust you. Here's the selection of reusable libraries, idioms, and conventions we've created for you to use, a la carte. When you feel it's time to address problems that these address, we'd like for you to pick from these first. If they don't fit your use-case but are in the same problem domain, let's have a discussion about whether it's appropriate to augment them to fit your use-case or whether we should use some other existing open source library, or even create a new library." I also think it makes sense that when creating new libraries, etc., that we discuss those on the list so that engineers with existing solutions/thoughts on problem spaces can contribute. This helps ensure that everyone is on the same page and that they're aligned with the library when it comes time to use it. For example, AFAICT the first time that the fast-list/gaia-fast-list effort was mentioned on our mailing lists was when Music NGA landed[2]. Andrew 1: For specific examples: * The email app adopted preliminary use of custom elements. A bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1176829) in the custom elements implementation was reported to the DOM team and acknowledged on July 9th. A fix landed over two months later on September 18th. * The email app switched over to requestsync from mozAlarms, making email's periodic sync unreliable for approximately 8 months. (Noting that since flame device clocks had serious reliability issues over that extended time period and there were also several mozAlarms issues that were only more recently fixed, it was not immediately obvious that requestsync was broken until the other issues were ironed out.) 2: Note that I'm just using gaia-fast-list as an example because it's an important implementation to performant apps but was not particularly discussed and there was prior art/effort within the gaia repo by multiple functional teams. It seems pretty cool, quite well documented and exampled, and with some model enhancements to not require the entire model to be synchronously available to the list implementation, would be suitable for email. Although the shadow root issues and the fact that the email app does its nefarious localStorage HTML cache at a higher level mean that there would be non-trivial effort to change and a potential startup time regression, so that's an example of where it would not make sense to change-over unless there was already a fundamental refactoring under way and the life-cycle issue and shadow root issues had been addressed.
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
