----- Original Message ----- > 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. This is not exactly what we typically do when using project branches. We should review and treat code the same as we do for mozilla-central. It means it might take more time for a review iteration, but the code that lands is know to be "reviewed the same as it would for m-c" and that means we don't need to go back and re-review every code change in the future. I mentioned this to lloyd and ttaubert on IRC and we have agreement. > 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. Pulling from past experience, I would suggest waiting until we are done to push elm back into mozilla-central. The elm branch will have it's own Nightlies. We do not need to rush anything into mozilla-central and worry about using preferences or flags to control the new code. When worrying about "drift", all we need to do is merge mozilla-central back into elm on a regular basis. I would suggest every few days. Then, when we finally decide to push the elm work into mozilla-central, we won't have any drift, the code will all have been reviewed to m-c standards, and the features can land without worrying they only "half" work.
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
