On Mon, Sep 18, 2017 at 7:54 PM, Alex Davis <ada...@mozilla.com> wrote: > > Talking to Karlof in SF on Friday, he proposed something similar. Seems > like the second bullet would make the most sense. We stop fixing old > versions but don't prevent users from using them. This way we can be a bit > more aggressive with which version we want to support and it encourages > users to update. >
This seems to me to just maintain the status quo. The implicit assumption in not removing support for legacy integrations is that "keeping code around" has little to no cost. Keeping old code always has a cost, human and monetary. Being blunt, continuing to support legacy browsers is *already* slowing our development cycle, as a result, every feature costs more than it needs to. Not only that, but if we leave the code in place largely unmaintained, we have a security footgun waiting to happen. I advocate for a more proactive approach - I want to explicitly remove support for fx_desktop_v1 and fx_desktop_v2. I want to remove the code. I want to remove the tests. I argue that in the long run, this is the most responsible thing we can do for both Mozilla and our users. Saying "we won't fix new bugs for these integrations" is totally different to "we no longer care whether these integrations work," which is totally different again to "we are removing support for these integrations." The first implies we will keep the code and the tests in place to support existing integrations and will ensure existing behaviors do not regress. Ensuring legacy integrations still function is exactly what's slowing down our development cycle. My time is largely spent ensuring I haven't broken legacy systems, TBH, this is time I'd rather spend elsewhere. This time has an opportunity cost for this group, and it costs Mozilla real money. If we go a step further and say "OK, we'll keep the code, but we won't run the tests" is even worse. This keeps the complexity in place that slows down our development process, but leaves gaping holes in our knowledge about the integrity of the system. I can say with 100% certainty, this *will* lead to a broken experience for the user. If we are going to unknowingly break the user experience, let's be responsible, do so knowingly and give an upgrade path. Finally, what do we do if a major security problem is found in the unmaintained code? Do we ignore it? To me, that's the worst of all, that's downright irresponsible. We fixed security problems in Persona right up to the end, because it was the right thing to do. It was painful. I can't speak for Ryan, but I know I would have rather spent that time making FxA better instead. To use a slightly more recent example, adding "Connect Another Device" to signin could have probably been merged a few days earlier had legacy system support been dropped. It was a multi-day effort to ensure those legacy integration's functional tests were up to date and that we didn't regress any behaviors. I have a hard time believing Mozilla will see a ROI > 1 from that work. To me, the only the only two responsible paths are 100% support, knowing we are going to continue to sink costs into maintenance, or 100% remove support. Shane
_______________________________________________ Dev-fxacct mailing list Dev-fxacct@mozilla.org https://mail.mozilla.org/listinfo/dev-fxacct
