#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs