You make great points Shane. Are there releases where we changed big chunks of FxA and in turn result in us dragging around old code and overhead? If so, what are they? Which versions do we REALLY want to avoid supporting moving forward?
We should overlay those big milestones with the ESR versions and the user breakdown. The answer might be more obvious to us then. -- Alex Davis // Mountain View Product Manager // FxA & Sync (415) 769-9247 IRC & Slack: adavis On Wed, Sep 20, 2017 at 7:06 AM, Shane Tomlinson <stomlin...@mozilla.com> wrote: > > > 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
