[tbb-dev] Thoughts about future Tor Browser plans

[Georg Koppen]

Matthew Finkel:
> Hi everyone,
> 
> (tldr; read the last paragraph)
> 
> In October [0] we were very excited about the prospect of all Tor
> Browser platforms following the Firefox Rapid Release schedule. However,
> in April (now), Android is still the only platform following the rapid
> release train and Windows, macOS and Linux remain on the extended
> support release (ESR).
> 
> As we move closer to the next ESR transition, this year it is beginning
> at Firefox 91 in May [1], I am wondering whether we should reverse
> course and slow down. At this point, we cannot safely transition all
> platforms onto the rapid release train before October (when 78esr
> reaches its EOL), so the only option is moving all desktop platforms
> onto FF91esr and then evaluate migrating onto the rapid release train
> after that.
> 
> Unfortunately, we are still a very small team, and the current situation
> is already pushing our team to its limits. Yesterday I spoke with Georg
> about another subject, and he briefly mentioned the idea of keeping the
> desktop platforms on ESR instead of moving onto the rapid releases. This
> alone wouldn't make much difference, and I previously discarded this
> idea, because we're already fighting all of the code churn for Android
> (although some of the code, like the automatic updater, is not used on
> Android). The important piece of this plan is reducing Fenix's burden,
> too. 
> 
> My current thought is that we move desktop platforms from 78esr to
> 91esr, and we begin rebasing our Fenix branches (and dependencies) only
> every 2-3 months. The only exception is geckoview where we continue

So, for the timeline for that plan: this change is going to happen with
the ESR91 transition? Or now? Or after it?

> rebasing our geckoview branches on the existing schedule. In addition,
> we drop desktop patches from the geckoview branches, and Android patches
> from the ESR branches. We could've (and should've) done the latter
> simplification earlier, but the former change makes future ESR
> transitions a little more complicated. I think we can live with that.

I have three concerns with that plan:

1) Getting rid of mobile patches on desktop and vice versa sounds like a
good idea on first glance. However, that would mean extra work for our
test suite part as right now we require Linux builds (and thus desktop
patches, too) to be sure non of our (GecKoView) patches requires
(further) changes. One could argue we could drop that part as those
tests are, to a large extent, desktop related tests anyway. I am not
sure whether you wanted to make that point, though (and there *are* a
bunch of tests that test functionality for mobile as well)

2) We have seen in the past while working on toolchain updates that the
GeckoView, android-components, and Fenix parts are quite tightly
coupled. You see that at the Gradle dependencies they require and that
things broke already during build when the wrong GeckoView version got
mixed with android-components/Fenix due to API incompatibilities. Just
focusing on continuous GeckoView rebasing while ignoring the other parts
will likely hit that problem again causing us to have extra work fixing
that up. (Even without *that* extra work there will be additional work
needed for de-coupling the those above mentioned tightly coupled
projects on the build side, even though we might feel this could be
acceptable)

3) Somewhat related to 2) I am worried about instability we introduce by
de-coupling GeckoView, android-components, and Fenix. It's often not
seen (as it is hardly visible on desktop either) but we greatly benefit
from all the testing Mozilla is running on those three components. But
that testing is *only* valid if we follow the GeckoView +
android-components + Fenix pipeline as close as we can. What happens
with your plan is that me move straightly into untested territory and I
doubt we can compensate for that given the resource issues you cite.

Georg

> - Matt
> 
> [0] https://lists.torproject.org/pipermail/tbb-dev/2020-October/001154.html
> [1] https://wiki.mozilla.org/Release_Management/Calendar
> _______________________________________________
> tbb-dev mailing list
> tbb-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20210408/6985f531/attachment.sig>