I talked to Gavin yesterday and we think the best approach would be to back out the Session Restore changes for now as they don't provide a real benefit other than code cleanup (and don't block any other work).
The plan would then be to re-land them *with* a kill switch in the same cycle that brings Australis - so we would need to prepare and keep those patches ready. The reasoning is that we indeed will break different add-ons than Australis but at least there will only be one release with a couple of add-ons breaking instead of two in a row. For bug 838577 we will probably need to maintain a shadow tree as Johnathan mentioned. I would suggest we talk to Ehsan as he has experience in doing this successfully. - Tim On 05/22/2013 03:40 PM, David Rajchenbach-Teller wrote: > Opening Bug 874817 to add that kill switch. > > Just for clarification: we might kill add-ons that specifically look at > the contents of undocumented private data structures. The advance > warning is here because we know that some such add-ons exist. > > Given that all these refactorings take place on a single file, it might > make sense to just backout the changes if necessary. > > Cheers, > David > > On 5/22/13 3:35 PM, Johnathan Nightingale wrote: >> 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 >> > > -- Tim Taubert Firefox Engineer ttaub...@mozilla.com _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
