[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                |  Actual Points:
Parent ID:  #33659                    |         Points:
 Reviewer:                            |        Sponsor:  Sponsor58-must
--------------------------------------+--------------------------------

Comment (by gk):

 Replying to [comment:15 acat]:
 > Replying to [comment:13 gk]:
 > > 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).
 > I think this makes sense, having just the minimum number of branches
 needed for now.
 >
 > Just to make sure we're on the same page. I assume that from `android-
 components`, we only care about `geckoview_beta`, the version of which is
 set in `Gecko.kt` with `beta_version`. And, in case we have to patch
 `components/browser/engine-gecko-*`, we will only patch
 `components/browser/engine-gecko-beta` and not `components/browser/engine-
 gecko-nightly` or `components/browser/engine-gecko`, right?

 Yes, that's the state of things for now at least.

 > I understand that `geckoview_beta` will always point to a geckoview
 build which is based on some commit of the `mozilla-beta` branch. So,
 whenever some `android-components` branch that we track bumps
 `geckoview_beta` (e.g. every 2-3 days), are we going to create a new
 corresponding mozilla-beta branch and apply our patches on top? That will
 probably mean creating many branches, but I guess it's ok. Maybe an
 alternative would be reusing mozilla-beta branches for a while by merging
 the newer changes and not trying to keep our patches in the top, and only
 create a new rebased branch for big changes (e.g. releases). But I guess
 creating a new branch for every `geckoview_beta` is simpler and, assuming
 the potentially large number of branches is not an issue, preferable.

 So first, the `android-components` model is similar to the Fenix one I
 mentioned in comment:8: There is only the `master` branch in that project
 and then some release branches/tags. And the releases I checked (v39.0 and
 v37.0) are directly made from the `master` branch. If there is a need for
 point releases (as for v37.0.X) they are made from the respective release
 branch.

 Second, the pacemaker for us is our ability to keep up with geckoview beta
 rebasing (and then reviewing and testing the results before pushing that
 to our repo for nightly builds) given that it will involve the vast
 majority of our patches. I don't remember whether we decided on a
 frequency for those rebases yet but for the sake of argument let's assume
 that means once per week.

 So, let's start with b1 on a Monday like today where nightly goes to beta
 (it seems b1 is getting released the same day or maybe one day later). We
 rebase our geckoview patches for that. Let's assume it takes until
 Thursday until we have this reviewed and ready for nightlies. It seems on
 `android-components` the merge day happens one day after the Mozilla merge
 day. Either way, once `android-components` has picked b1 up we rebase our
 patches for `android-components` and use the commit where b1 got picked.
 And once Fenix picks up that commit we do the same with our Fenix patches.
 I assume the whole process will take the first week in the new cycle. And
 then we repeat (even though we might a bit faster subsequently in the
 process)

 All in all I'd assume one new branch per repo per beta we use. I think
 that's not too crazy.

 > I was also thinking about the `merge day` steps for `android-
 components`, especially this `engine-gecko-nightly` -> `engine-gecko-beta`
 -> `engine-gecko` folder renaming. I was not sure how this would affect us
 in case we have patches to some of those `components/browser/engine-
 gecko*` folder. But since for now we are only going to use `gecko-beta`,
 we will only (possibly) patch `components/browser/engine-gecko-beta`, so
 the only thing is that we probably will have to resolve conflicts due to
 the merge_day `engine-gecko-nightly` -> `engine-gecko-beta` renames. I
 hope there are no weird issues with the git rebase automatic rename
 detection, like some patch being applied to `engine-gecko` instead of
 `engine-gecko-beta`, but hopefully we will catch that if it happens :)

 Well, I'd expect the majority of conflicts to come from the `android-
 components` merge day, yes. That is in the first week of the geckoview
 release cycle. But there are a bunch of changes that makes it to `engine-
 gecko-beta` outside of the merge day changes. So, I'd expect whenever we
 pick up a new `android-components` commit (due to a new mozilla beta)
 we'll have some (smaller) conflict resolution to do.

 (Note: this is all without having the `application-services` included, but
 *if* we need to include parts of that code, too, I don't think the overall
 picture outlined above will change substantially)

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