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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 gk):

 Replying to [comment:11 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 `geckoBeta`/`fenixProduction`.
 >
 > 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.

 Maybe. I guess it's still up in the air how this will develop. I think we
 should follow closely what the Fenix project is using right now keeping in
 mind to amend our plans as things evolve.

 That means e.g. there is no beta branch on Fenix whatsoever right now.
 Moreover, as I pointed out above, Fenix beta releases and regular releases
 are essentially the same: there is no week between them. So, given the
 current state of affairs we are stuck with building
 `geckoBetaFenixNightly` (or `geckoBetaDebug` assuming that means
 `FenixNightly`) for our nightlies and once Fenix is moving to beta (that
 is a *release* branch is created) we have the sole option to have one or
 two builds testing the upcoming release config (with the stable android-
 components) from that branch before we need to use the
 `geckoBetaFenixProduction` flavor.

 > 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.

 Moving to `geckoNightly` means we need to start rebasing our patches to
 mozilla-central and not onto mozilla-beta anymore (there is no point using
 `geckoNightly` when we build `geckoview` from `mozilla-beta`) which is
 currently not planned according to S58 at least. We likely need to have
 our automatic rebasing setup for that. Thus, I am skeptical that we get to
 using a `geckoNightly` flavor going this year, especially as we'll have
 S30 work in parallel and we are only 3 people. But, yes, in the glorious
 future it seems worth thinking about how we can switch to `geckoNightly`
 so that our nightly users are testing that.

 > 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.

 The same "Maybe" as above. Again, right now I am mostly interested in
 figuring out what we need for a setup to get the whole machine going in,
 say, the next couple of weeks. As to branches that we currently (and in
 the coming couple of weeks) need, I think, we are at:

 a) our patches rebased regularly onto `mozilla-beta` for the `geckoview`
 part (1 branch for `geckoview` to track)
 b) patches rebased regularly onto `master` and `releases/$VERSION` (for
 `38.0` there is no release branch (yet) thus we need to create one based
 on the latest tag instead) for `android-components` (about 2 branches for
 `android-components` to track)
 c) patches rebased regularly onto `master` and `releases/$VERSION` for
 `fenix` (2 branches for `fenix` to track).

 > 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.

 I am somewhat optimistic that only the `geckoview` part is timeconsuming,
 and actually, that's likely only to happen once a new `mozilla-central`
 comes down into the beta branch. Apart from that the changes should not be
 that big (mozilla-beta) or the code base is just not a large/problematic
 (android-components/fenix). Although, the latter will highly depend on how
 much and what we need to patch out/change.

 > > 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.

 Not just the testsuites but getting the whole thing to build again, yes. I
 suspect we'll be mostly good for the non-`master` (that is `releases`)
 branches but looking at some of those there are sometimes updates on them
 that make it necessary as well to recreate the dependencies.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs