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