As far as I know, Tim is right on both accounts: 1) It requires a lot more man power for stabilization on a different branch esp of gecko. You can ask releng as well how much manpower it takes for sheriffing, stabilization and uplift for each of the branches
2) The biggest issue in branching off from master is that the newer features require new gecko apis. We all need to work together to make sure all products are stable on master, or we should just switch over to use aurora instead, which means that you won't have the APIs until the next nightly -> aurora push... On Fri, Nov 13, 2015 at 1:50 AM, Tim Guan-tin Chien <[email protected]> wrote: > The MOZ_RELEASE build flag is a powerful tool to run are test emerging > feature. On a train model. > > Cross-team communication on schedule and roadmap planning are the right > path toward preventing your problem. Otherwise we will not be able to > stablize platform features on B2G. > > (B2G also happen to use Gecko very differently for some reasons, require > more engineering and stabliation, as Service Workers have shown) > > > Tim > > Julien Wajsberg <[email protected]> 於 2015年11月13日 星期五寫道： > > Lately, discussing with some folks like Nicolas Pierron from the JS Engine >> team, I wondered if we should enable not-yet-stable things like this at all >> on B2G. >> As a good example, recently we had an issue with the "class" ES2015 >> feature: once we branched, l20n stopped working. This would not have >> happened if the unstable feature had been disabled on B2G. >> >> Maybe we should consider Gecko Nightly in B2G just like a release, with >> all release-disabled features disabled as well. >> >> Le 12/11/2015 19:08, Dale Harvey a écrit : >> >> I am fairly sure it would be appropriate to do the same as Desktop & >> Android here, filed a new bug >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1224283 >> >> On 12 November 2015 at 18:03, Daniel Holbert <[email protected]> >> wrote: >> >>> On 11/12/2015 09:46 AM, Dale Harvey wrote: >>> > As far as I can tell navigator.serviceWorker is now available in >>> Firefox >>> > Desktop nightly, so does that mean the next gecko update to nightly >>> will >>> > support it? >>> >>> I don't know anything about serviceWorker plans, but I'll clarify the >>> current state of Nightly enabled-ness, from a bit of poking around at >>> prefs files: >>> >>> * By default, serviceWorker support is disabled in Gecko: >>> >>> https://mxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js?rev=16fc1974dab6#149 >>> >>> * Firefox & Fennec override that default & opt to enable serviceWorkers >>> by default, but only for *non-release* versions of Firefox & Fennec: >>> >>> https://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js?rev=73f07190af6d#1650 >>> >>> https://mxr.mozilla.org/mozilla-central/source/mobile/android/app/mobile.js?rev=84a7cf29f4f1#947 >>> >>> * b2g could presumably do the same, if that were appropriate (not sure) >>> -- but it doesn't currently, and in fact it has serviceWorkers >>> *explicitly* disabled (technically unnecessary I think given the all.js >>> default), due to some mulet issue: >>> >>> https://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js?rev=0d3a6fcb8687#1130 >>> >> >> >> >> _______________________________________________ >> dev-fxos mailing >> [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
