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

[Tor Bug Tracker & Wiki]

#33184: Support for Fenix
--+
 Reporter:  sisbell   |  Owner:  gk
 Type:  enhancement   | Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam202005  |  Actual Points:
Parent ID:  #33659| Points:
 Reviewer:|Sponsor:
  |  Sponsor58-must
--+

Comment (by gk):

 Replying to [comment:22 acat]:
 > I noticed that there is the `EARLY_BETA_OR_EARLIER` define which
 controls several prefs, for example the one controlling whether
 `SharedArrayBuffer` is enabled or not (not implying that
 `SharedArrayBuffer` is still dangerous, just as an example). And by taking
 a look at the latest Fenix releases:
 >
 > {{{
 > v4.1.0
 > 36.0.2
 > 75.0.20200309155231
 > EARLY_BETA_OR_EARLIER=1
 > has SharedArrayBuffer
 > }}}
 > {{{
 > v4.2.0
 > 37.0.0
 > 75.0.20200322132212
 > EARLY_BETA_OR_EARLIER=
 > does not have SharedArrayBuffer
 > }}}
 > {{{
 > v4.3.0
 > 38.0.0
 > 76.0.20200406152003
 > EARLY_BETA_OR_EARLIER=1
 > has SharedArrayBuffer
 > }}}
 > {{{
 > v5.0.0
 > 39.0.1
 > 76.0.20200424000239
 > EARLY_BETA_OR_EARLIER=
 > does not have SharedArrayBuffer
 > }}}
 >
 > I'm not sure if it's intended that there is one Fenix version with early
 beta and another with late beta alternatively, or it is a coincidence.
 This might not be an issue if they are going to move to gecko-release for
 Fenix release, but just mentioning it here just in case we want to take a
 look at these kind of issues. With some pinning tests like the
 `dom_enumeration` ones, but for `prefs` we should probably be able to
 catch these issues, so that might be a good idea to have for Fenix.

 Indeed, it is. What you see stems from the fact that the release cycles
 between GeckoView and Fenix are not aligned (yet). So, we need to catch
 those issues. I heard the plan is to align those cycles at some point (and
 Fenix release using GeckoView release etc.), though, but it's not clear
 when exactly this will happen and how we would deal with that.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#33184: Support for Fenix
--+
 Reporter:  sisbell   |  Owner:  gk
 Type:  enhancement   | Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam202005  |  Actual Points:
Parent ID:  #33659| Points:
 Reviewer:|Sponsor:
  |  Sponsor58-must
--+
Changes (by acat):

 * cc: tbb-team (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#33184: Support for Fenix
--+
 Reporter:  sisbell   |  Owner:  gk
 Type:  enhancement   | Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam202005  |  Actual Points:
Parent ID:  #33659| Points:
 Reviewer:|Sponsor:
  |  Sponsor58-must
--+

Comment (by acat):

 I noticed that there is the `EARLY_BETA_OR_EARLIER` define which controls
 several prefs, for example the one controlling whether `SharedArrayBuffer`
 is enabled or not (not implying that `SharedArrayBuffer` is still
 dangerous, just as an example). And by taking a look at the latest Fenix
 releases:

 {{{
 v4.1.0
 36.0.2
 75.0.20200309155231
 EARLY_BETA_OR_EARLIER=1
 has SharedArrayBuffer
 }}}
 {{{
 v4.2.0
 37.0.0
 75.0.20200322132212
 EARLY_BETA_OR_EARLIER=
 does not have SharedArrayBuffer
 }}}
 {{{
 v4.3.0
 38.0.0
 76.0.20200406152003
 EARLY_BETA_OR_EARLIER=1
 has SharedArrayBuffer
 }}}
 {{{
 v5.0.0
 39.0.1
 76.0.20200424000239
 EARLY_BETA_OR_EARLIER=
 does not have SharedArrayBuffer
 }}}

 I'm not sure if it's intended that there is one Fenix version with early
 beta and another with late beta alternatively, or it is a coincidence.
 This might not be an issue if they are going to move to gecko-release for
 Fenix release, but just mentioning it here just in case we want to take a
 look at these kind of issues. With some pinning tests like the
 `dom_enumeration` ones, but for `prefs` we should probably be able to
 catch these issues, so that might be a good idea to have for Fenix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#33184: Support for Fenix
--+
 Reporter:  sisbell   |  Owner:  gk
 Type:  enhancement   | Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam202005  |  Actual Points:
Parent ID:  #33659| Points:
 Reviewer:|Sponsor:
  |  Sponsor58-must
--+
Changes (by gaba):

 * status:  new => assigned
 * owner:  tbb-team => gk


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam202005  |  Actual Points:
Parent ID:  #33659| Points:
 Reviewer:|Sponsor:
  |  Sponsor58-must
--+

Comment (by gk):

 To continue what I wrote in comment:8: Fenix 5.0 is out:

 5.0 release
  - branching off 2 days before release
 (`2c18c255da0bdcc48ec7deda3ce64b97797cce75` merge base with `master`), no
 beta releases before that and `android-components` got pinned to a stable
 version (39.0.0) for first beta, which got out two days before 5.0.

 Noteworthy as well that the release cycle is not aligned to the one for
 GeckoView.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam202005  |  Actual Points:
Parent ID:  #33659| Points:
 Reviewer:|Sponsor:
  |  Sponsor58-must
--+
Changes (by gk):

 * keywords:  tbb-mobile => tbb-mobile, TorBrowserTeam202005
 * priority:  Medium => Very High


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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

Re: [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
--+
Changes (by gk):

 * keywords:  tbb-mobile, Android => tbb-mobile
 * cc: sysrqb, boklm (removed)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  #33659| Points:
 Reviewer:|Sponsor:  Sponsor58-must
--+
Changes (by pili):

 * parent:   => #33659


Comment:

 Parenting to S58 O2.2

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  Sponsor58-must
--+

Comment (by 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?

 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.

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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  Sponsor58-must
--+
Changes (by pili):

 * sponsor:   => Sponsor58-must


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 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

Re: [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 gk):

 Replying to [comment:11 sysrqb]:

 [snip]

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

 It's the default target Mozilla is [https://github.com/mozilla-
 mobile/fenix#build-instructions suggesting] in `./gradlew clean
 app:assembleGeckoBetaDebug`. I am not sure what it builds in Fenix land
 [https://github.com/mozilla-mobile/fenix/blob/master/app/build.gradle#L154
 it says] just `debug`. My guess, though is it's using Fenix nightly code.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 gk):

 We *could* think about building `geckoBetaDebug` but maybe that's more for
 devs actually debugging Fenix code than our nightly audience

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 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.

 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 gk):

 Here come some release cycle notes I collected that should help us
 determine which combinations of components we want to base our nightly and
 release builds on:

 The release cycle for mozilla-* code is 4 weeks which means 3 weeks 3
 betas each and one week with 3 rcs (affects GeckoView)

 For Fenix we have beta and nightly versions with geckoview on
 beta/nightly. In particular Mozilla builds

 a) nightly:geckoBeta/fenixNightly and geckoNightly/fenixNightly (only
 latter is published to Google Play)
 b) beta:   geckoBeta/fenixBeta
 c) production: geckoBeta/fenixProducion

 (Yes, the release version of GeckoView is currently not used it seems)

 android-components used on Fenix `master` is updated daily by a bot to the
 latest nightly version

 geckoview used on android-components' `master` is updated daily by a bot
 to the latest nightly version and to the latest beta every 2-4 days (I
 suspect that corresponds to the 3 betas each week above)

 See: `docs/contribute/merge_day.md` for what happens during merge days in
 the android-components repository.

 How does branching and release tagging for Fenix currently look like?

 4.3 release
   - branching off 1 week before release
 (`7f1ef17d8b4b6aa5381819ef7a7ab822668b05c1` merge-base with `master`), no
 beta releases before that and android-components got pinned to a stable
 version for release on first beta which got out 3 days before the final
 release
 4.2 release
   - branching off 1 day before release
 (`301f56d144754e6c26f7e390952f35287185dfd4` merge-base with `master`), no
 beta releases before that and android-components got pinned to a stable
 for release on first beta which got out 1 days before the final release

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 gk):

 Replying to [comment:6 sisbell]:
 > I'm working through this using tbb android-components generated
 artifacts as dependencies. I haven't checked in the changes as I'm still
 working through but what I have found its
 >
 > We can modify buildSrc/src/main/java/Dependencies.kt to match android-
 components dependencies we build
 >
 >
 > {{{
 > const val mozilla_android_components = "36.0.0"
 > }}}
 >
 > I removed a number of projects from android-components so those
 references have to be removed from as dependencies in app/build.gradle
 >
 > I also added legacy plugin support, same as in android-components
 >
 > The telemetry can be easily disabled for runtime, will require a simple
 patch. I still will need to verify the impact on compile time, having
 removed the artifact dependencies as well.
 >
 > There's also a number of build variants to we can configure for beta,
 nightly and some others which add debugging builds, etc.
 >
 > fenix uses SDK 28 (while toolchain, android-components uses 29). I'll
 align these.

 I just realized this is not just a meta ticket (as indicated by the
 description). It seems, though, just the one extra patch is not enough
 anymore (just declaring `mavenLocal()` is not making it for me). There are
 issues with aligning the SDKs as well (see comment:13:ticket:33557). Let's
 keep this as meta ticket and use #33927 for the Fenix `tor-browser-build`
 changes?

 If you want to work on the fenix part (again) let me know. I was under the
 assumption you'd focus on the geckoview part currently and picked this up.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:
--+--
Changes (by sisbell):

 * cc: eighthave (removed)


Comment:

 I'm working through this using tbb android-components generated artifacts
 as dependencies. I haven't checked in the changes as I'm still working
 through but what I have found its

 We can modify buildSrc/src/main/java/Dependencies.kt to match android-
 components dependencies we build


 {{{
 const val mozilla_android_components = "36.0.0"
 }}}

 I removed a number of projects from android-components so those references
 have to be removed from as dependencies in app/build.gradle

 I also added legacy plugin support, same as in android-components

 The telemetry can be easily disabled for runtime, will require a simple
 patch. I still will need to verify the impact on compile time, having
 removed the artifact dependencies as well.

 There's also a number of build variants to we can configure for beta,
 nightly and some others which add debugging builds, etc.

 fenix uses SDK 28 (while toolchain, android-components uses 29). I'll
 align these.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 sisbell):

 This is preview. It has similar problems as #33556 with working with
 network disabled. You can see in the gradle-dependencies-list there are a
 bunch of snapshots for the android-components. These snapshot hashes will
 change without warning so those will be replaced with the ones that will
 be packaged locally from the tbb android-components build.

 !https://github.com/sisbell/tor-browser-build/commits/bug-33184

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 sisbell):

 Replying to [comment:2 sisbell]:


 > So this first issue we have to resolve is this one
 >
 > https://github.com/mozilla-mobile/fenix/issues/6932
 >
 > Fenix doesn't build out-of-the-box on a clean clone of the repo.
 >
 This caused by not having ANDROID_SDK_HOME and ANDROID_NDK_HOME properties
 set. Since this is handled by the android-toolchain setup, its not a
 problem for the tbb build.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:
--+--
Changes (by sisbell):

 * cc: bolklm (removed)
 * cc: boklm (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 sisbell):

 So this first issue we have to resolve is this one

 https://github.com/mozilla-mobile/fenix/issues/6932

 Fenix doesn't build out-of-the-box on a clean clone of the repo.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:
--+--
Changes (by sisbell):

 * owner:  (none) => tbb-team
 * component:  - Select a component => Applications/Tor Browser


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs