Hello everyone!
We have been working the last few months on getting mobile Tor Browser
hooked into the rapid release train, away from the ESR series. It's been
exciting all around. We are close to releasing a first stable mobile
release and are getting used to the process of frequently updating
toolchains, different patch sets, and auditing new code. It's time for
looking forward and thinking about desktop Tor Browser.
Getting desktop To Browser onto the rapid release train at the same time
while maintaining the mobile part + having additional sponsor work on
our plate is very likely too much for our 2 1/2 current browser devs.
So, we originally thought about postponing that until we have more
capacity. But maybe we can be smarter.
It's not desktop vs. mobile but more that we have 4 different platforms
we support and the first one, Android, made it onto the rapid release
train. What if we moved the others platform by platform to test how hard
it is and just move forward if we are confident we can handle the workload?
I'd propose we start with Linux on the non-ESR train next and soon. That
means switching Linux nightlies, or if we are confident, even Linux
alphas, too, off ESR.
Now, how well works this with
1) Toolchain updates:
I think there are no large issues to expect as we need to update
compilers etc. anyway for mobile. With tor-browser-build#40125 fixed we
are back to a somewhat reasonable project structure and making the
necessary changes for Linux should just be some additional lines in a
small part of config files and build scripts. This should be manageable.
2) tor-browser patch rebasing:
I think, too, here are no issues to expect. We already need to rebase
all the patches for mobile and are not skipping the desktop-only ones.
3) desktop-specific code parts
That's the item with the biggest uncertainty to me given that we
basically ignore the desktop-only parts to a large extent (apart from
making sure things are compiling) when preparing for mobile.
There are two parts to it: a) torbutton/tor-launcher and b) the updater.
We already fixed Torbutton code in the past for changes introduced after
ESR 78. Extrapolating from that experience I am not too worried about
either Torbutton or Tor Launcher. The updater is an unknown here but
looking over the changes we need(ed) to make for tor-browser rebasing
they seem farily small and uncontroversial, so I am not too pessimistic
here either.
4) Test suite (tor-browser-bundle-testsuite)
We have updating the test suite for new mozillaXX milestones already on
our ToDo list when preparing new mobile releases (see:
tor-browser-bundle-testsuite#40008 and #40009 for examples). And now the
important part: we need to build Linux builds for that task anyway. So,
we would actually benefit here from officially moving Linux off the ESR
train without any additional costs test-suite-wise.
5) Proxy bypass/feature/closed bugs audit
We do all those audits already for mobile. No additional work for any of
the desktop platforms is needed (apart from having the respective
platforms in my, too, when going over, say, all the closed Mozilla bugs).
Now, if we start soon-ish (e.g. with mozilla84 landing on beta) we even
have enough time to get accustomed to and test the whole process so that
we can think about releasing 10.5 with Linux off the ESR train and/or b)
adding macOS and Windows (in that order) to the rapid release wagon as
well in the not too distant future.
If we still feel uncomfortable with having Linux or any of the other
desktop platforms off ESR for 10.5 then it should not be too hard to
leave those platforms on the alpha/nightly series on rapid release and
go for them with ESR for 10.5. So, the risk for not stabilizing 10.5
and not shipping a good 10.5 because of the above proposal should be low.
Georg
