So ttaubert and I were talking on IRC looking to land the implementation of a container to host HTML auth flow (hammered out by zach and vlad).
Meta question came up, ttaubert asks - "should that code match m-c quality already? how is that merged? what/where is elm?" Here's the proposal: Basic idea: Elm is not quite up to the same quality as m-c. We move faster. In the desktop case, we need to keep gavin and ttaubert up to speed on how the work is going, so they're CC'd. On the android side, it's nick and mark's choice. We land more aggressively on elm to get to a point where we can uplift. Uplift process is you create a patch and at that point a stoic solid review can be done of the whole thing. When do we uplift? How about Weeklyish. Not so often that there's overly-much process, but frequently enough that we avoid annoying merge issues and don't drift too far from m-c. Initial criteria for uplift? How about a pref that's default off that hides all this work, and testing to ensure no regression in nearby functionality? (hey jbonacci, did you hear that? I said testing! Here's a place that might work great. We throw a build at you and describe where the work has been, and give you hints as to what we might have regressed in mainline firefox.) lloyd _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
