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