Sorry I let this discussion languish. *I think pre-releases sound like a good idea that will address some of our issues.* For this email, I just want to elaborate with real examples to clarify some of the issues we've been having (disclaimer: I may not remember them 100% accurately).
On Wed, Oct 3, 2018 at 8:40 PM Stefan Arentz <sare...@mozilla.com> wrote: > > On Tue, Oct 2, 2018 at 6:07 PM Michael Comella <mcome...@mozilla.com> > wrote: > >> >> 1) The way the product and components release schedules happen to align >> *makes >> us find and fix bugs/design issues later than we'd like.* The product >> sprints/releases are every two weeks, we code freeze on the second >> Wednesday, and finish our build end-of-day Friday. afaik, components >> releases sometime between Wednesday and Friday which means we're sometimes >> updating the potentially unstable components [1] after code freeze, >> creating a lot of stress on both teams to fix bugs or design issues by the >> end of the week. >> > > Well, don't upgrade then at that point in time. If there is no reason then > do not upgrade? > For a real example where there were reasons to upgrade and reasons not to upgrade, we shipped a release and discovered a components bug around the keyboard. For the next release, the bug is fixed in components so we want to upgrade components. However, the components upgrade forced us to use updated APIs – the new Settings API broke the extension function workaround we were using – and introduced additional bugs we needed to diagnose, report, and address (i.e. fix or wait for a fix) during the sprint cycle. > > >> 2) *Components updates unexpectedly break existing integrations* (e.g. new >> Settings <https://github.com/mozilla-mobile/firefox-tv/issues/1204>), >> adding unplanned work to our sprints. >> > > Assuming you talk about API changes: we try hard to prevent breaking > changes. In the unfortunate case when it is needed we write about it in the > release notes. If you are uncomfortable about upgrading, ask us. We can > always make time to help with that. > It's less about explicit API changes and more about unintentional bustage: see the example above. For an enumeration of bustage we face, there are 1) new components code breaking existing work-arounds (example above), 2) missing functionality in components that replaces WebView-based functionality (which take time to investigate and build), 3) incorrect integrations (e.g. leaving out an edge case bug fix like FocusedDOMElementCache), and 4) API design issues (e.g. unable to access `evaluateJavaScript` which we depend on). I don't have a great solution for this but... > > One of the reasons to use snapshots would defintiely be to find problems > early. > These early snapshots (or pinned pre-release versions) would definitely help, I agree. > > One thing we did recently in Focus may be worth thinking about: we had a > PR with a large refactor in Focus to integrate with the browser-session > component. Because of the size of this PR, we asked QA to regression test a > build coming from the PR branch. This uncovered a number of issues that we > then dealt with before the patch landed. > > You could consider doing the same thing when you pull in a components > update; do it on a PR branch and have QA test it. > This is a great idea – thanks for the suggestion. > > 3) *Patching previous releases seems to have a lot of overhead.* >> Sometimes a product is forced to pin their versions for stability or lack >> of engineering time to integrate breaking changes (see above) but it's >> seemed difficult to quickly backport bug fixes. From this thread, it sounds >> like the components team is addressing this though. 👍 Also, finding bugs >> sooner (the point of this thread!) would make *quick* backports less >> necessary. >> > > We are addressing our ability to more easily publish bugfix releases. But > whether a bug can actually be backported will have to be decided on a > bug-by-bug basis. It is not really a given that everything is easily > backported or fixable in an older release. There may be a case where the > answer is: this is better fixed by upgrading. > Makes sense: we want to ship the best products possible while minimizing unnecessary engineering overhead. But upgrading sometimes brings us back to problem 1. In this situation, perhaps it'd be good to have an explicit discussion between the product team and the components team about the trade-offs (e.g. engineering time, stability, roadmaps, etc.) to make a decision about which approach to take. > > This is a bit theoretical, but I do want to set expectations. > Understood, thanks. I hope my examples help elaborate on the problems we've been seeing! fwiw, in the future, I think this will be less of an issue because we'll no longer be replacing the core functionality of our app (since we're mostly done there). And again, *I think pre-release versions are a good idea that will likely address some of these issues.*
_______________________________________________ Sync-dev mailing list Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-dev
