On May 22, 2013, at 5:33 AM, David Rajchenbach-Teller wrote: > Unfortunately, we do not. > > For the current batch of clean-up changes, it is certainly possible to > add a kill switch. Time-consuming, certainly not nice (the kill switch > will creep in in dozens of places in the code, if not hundreds), but > possible. > > For the upcoming set of rewrite-half-of-the-code changes, though, having > a kill switch pretty much means forking the code of Session Restore into > an "old" session restore and a new one. > > Do we have a policy on these things?
Policy[1] is that whenever something lands on central, it is the developer's responsibility to provide for the ability to turn it off. Usually that's just a kill switch in cases where it makes sense, or a backout where the patch is unlikely to accumulate much change on top of itself in a given release. In cases where neither of those works (Ehsan's private browsing changes, or dmandelin's landing of ionmonkey in FF18) engineers have had to work harder to maintain that ability, e.g. by maintaining a shadow tree that doesn't have their patches, but has all the other landings. That's what Ehsan's pointing to in his reply. I agree with Ehsan that, one way or another, we'll need to be able to disable these changes if they cause too much bustage (though I'm very happy to know that we're cleaning up that code in general). J [1] http://mozilla.github.io/process-releases/draft/development_overview/ Ancient, and shows it, but still relevant for this case. See "Moving work from one channel to another" --- Johnathan Nightingale VP Firefox Engineering @johnath _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
