On Sat, Nov 21, 2015 at 2:07 AM, Andrew Sutherland < [email protected]> wrote:
> 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]. > Let me pile up a bit my personal opinion on your comments, and so on djs's comment. The state of the tree was clearly not intentional, or because of the lack of skills. The set of constraints you have described are one of the root cause of many things. In a limited timeframe, you can do a limited amount of work. And has you have described, you can spend it making one choice at a time - ignoring the other categories during this timeframe. Sounds criminal to blame Gaia developers, if you think about all the work that has been done with the amount of constraints. Now it is not clear to me what it is to be an engineer outside of the NGA group. It seems to me that since the beginning the speech of *engineers* that have decided to spent time on helping to prototype the proposed architecture has always been: This is a proposal, and there are many various pieces. Some of them may never happens, some of them will definitively helps, some will likely be transformed before the end, etc... But one of the core idea behind the proposal is: all the constraints you have mentioned will likely rise again. Whatever you skills are you will face again this situation and have to do choices. Promoting scoping and encapsulations at many levels should help to reduce side effects and should make the code easier to maintain and to understand. This is not a new idea, but the proposal is trying to enforce it with platform level features, at various levels. So you should think about it as: "Nobody is perfect. Anyone can fail under such constraints". Platform level enforced encapsulations would like to help to reduce the possible side effects. UI Components and modules, are other helping abstractions too. So, anybody who want to help to shape this high level structure for apps, and participate is part of the group. Actually Francisco keeps complaining that there is not enough people pissing on Service Worker ware, nor the Virtual list. Having more feedbacks to understand why a particular library does not fit your use case is great. Having patches to make it fit your use case is awesome. But in general those libraries are open to discussions. So, your "a-la-carte" wish, is basically what Francisco says since the beginning! Then it is unclear that there is a gap between what you want and where some spend their efforts. One of the contention point could be that there is a will to unify our apps architecture based on some of the lessons we have all learned in the past years. Now my next answer in this thread will try to answer a bit more directly djf's points, in order to try to refocus a bit on the initial subject of this thread. This answer will likely contradict a bit the "a-la-carte" point and the feeling that any app owner can do whatever it wants, when it wants - or when it feels it is time. Vivien. P.S: Virtual list has been mentioned multiple times in various thread under different forms since a bit less than 2 years now. The will to really deliver a solution has been captured in bug 1168076 (which lack a nice description i should admit). P.P.S: I agree on the lack of enough discussions on the mailing-list. But iirc they has been some trials earlier without much impacts :/ Francisco knows more than me on this subject. > 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 > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
