[tor-bugs] #33184 [Applications/Tor Browser]: Support for Fenix

[Tor Bug Tracker & Wiki]

#33184: Support for Fenix
--------------------------------------+--------------------------
 Reporter:  sisbell                   |          Owner:  tbb-team
     Type:  enhancement               |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-mobile, Android       |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by sysrqb):

 Replying to [comment:8 gk]:
 > Here come some release cycle notes I collected
 Thanks for analyzing this.

 Replying to [comment:9 gk]:
 > So, based on comment:8 I think what we do is base our fenix nightly
 build on a fixed fenix commit from the master branch and build
 `geckoBetaFenixNightly`. We update the commit a couple of times during a
 release cycle which needs in turn an update for the android-components
 nightly commit we build from (that is is needs to match match the
 respective fenix nightly is currently using). That is turns needs rebased
 patches to the geckoview beta we use.

 Let's see. Let's assume we only maintain Tor Browser "Nightly" and
 "Release" channels in the future. I agree that our nightly builds should
 be based on a "recent" version of `fenixNightly` (and this will probably
 become `fennecNightly`, in the future). I'm fine with beginning with using
 `geckoBeta` for the nightly builds, at least initially. Skipping ahead a
 few weeks, at the end of the current month, our Nightly branch becomes the
 new Beta. We aren't planning on publishing the beta channel at this point,
 but we should continue updating the Fenix commit (from the correct branch,
 along with the new required AC/GV dependencies) as bugs are fixed during
 the beta cycle. We should continue running the tests on this branch
 (`geckoBetaFenixBeta`), despite not releasing it. At the end of the
 following month, the beta branch becomes the new Release. I assume Fenix
 will add a `geckoRelease` in the future. That will lead to building
 `geckoReleaseFenixRelease` on release days.

 For our nightly builds, we can think about moving onto geckoNightly later
 this year. Using geckoBeta as a more stable base seems like a safe
 foundation for us, because we'll be dealing with many other moving parts
 and components.

 This means we'll take "snapshots" periodically of the many repositories we
 need (mozilla-beta, android-components, fenix, etc.) and we'll rebase our
 patches on top of the tip/head commit at that point in time (or an older
 commit, if that makes more sense). As we are following all three Fenix
 release trains, we'll need to follow this process for (up to) 9 branches
 (possibly 2 mozilla-beta branches , a mozilla-release branch, possibly 3
 android-components branches, and 3 fenix branches). We may be able to
 simplify this into 1 mozilla-beta branch such that `fenixNightly` and
 `fenixBeta` use the same version of GV for `geckoBeta`. We probably can't
 escape maintaining three patchsets for android-components. However, with
 all of this said, the "release" patchsets should only be rebased and used
 a few times during the month, if there are any point releases - and only
 once in general. So, "9 branches" is really "only" rebasing 5-6 branches
 periodically.

 This process sounds exhausting. We should think about how we can automate
 some of these. We can automate the "snapshot-and-rebase" piece of it (and
 this fits into the auto-rebasing plan we already have), and then we only
 deal with the merge conflicts, as needed. The test suites can be triggered
 when the rebasing is completed, as well.

 > A challenge will be all the Gradle dep updates every time and the
 different set of Gradle deps we now have to maintain for the nightly and
 the stable series.

 It would be nice if we can automate this process, too. And, I suppose,
 this is a prerequisite for automatically running the test suites after
 each rebase, as well.

 Replying to [comment: gk]:
 > We *could* think about building `geckoBetaDebug`

 What does this build? That isn't a valid target, from what I see. Do you
 mean simply `debug` or something like that? I think we shouldn't use non-
 debuggable builds for nightly, at least at the beginning. I prefer
 following Mozilla's lead on this until we're comfortable with our
 configuration and we know what we're doing.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33184#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online