[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #30461 [Applications/Tor Browser]: Update tor-android-service Project to Use Android Toolchain (Firefox 68)
#30461: Update tor-android-service Project to Use Android Toolchain (Firefox 68)
-------------------------------------------------+-------------------------
Reporter: sisbell | Owner: tbb-
| team
Type: defect | Status:
| needs_review
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: tbb-rbm, ff68-esr, tbb-9.0-must- | Actual Points:
nightly, TorBrowserTeam201908 |
Parent ID: #30324 | Points:
Reviewer: | Sponsor:
| Sponsor44-can
-------------------------------------------------+-------------------------
Comment (by gk):
Replying to [comment:12 sisbell]:
> I need to get review and merge of tor-android-service. Branch 0801a
contain all the latest changes from orbot to tor-android-service. There
are a lot of changes here since I've been keeping up with the work going
into Orbot.
>
> https://github.com/sisbell/tor-android-service/commits/0801a
>
> Revision 5c9583cf8e2b7002f71c2971aae7ebb44c067b42 on July 17th is the
minimum I think we can use, so that would cut down a lot of review time.
The changes after are not so critical for us.
Okay. I can see how that particular commit is relevant for us but I am not
so sure about the previous ones. What about we pick just that one for now
to unblock our nightly and alpha builds and think about the other ones
later on?
> How do we want to do this?
We can discuss this in one of our team meetings but here is how I think we
should do it: we treat tor-android-service as any of our other project.
That means proposed changes need a ticket on our bug tracker (right now
this is Trac but it might become Gitlab or $foo). Then someone needs to
write a patch, point to a branch (be that one on our own infrastructure,
or Github, Gitlab or...) and find someone to review and merge the changes.
The patch should a) be based on our master branch as we own the canonical
repo now and b) it should be written in a way that we don't have to
suddenly apply patches to any of our other projects. E.g. it's nice to
redo the VPN support part but the resulting patch should be written in a
way that we not have to suddenly apply `tor-browser-build` patches to rip
things out there. More precisely, it would be written in a way that
projects can make use of VPN support but others can safely ignore that
part to reduce attack surface etc. by setting a compile time option to
just not compile that part in in the first place.
Does that make sense? If so, please file new tickets for the changes we
should make in `tor-android-service`, point to the patches (please base
them on our `master` branch to make merging easier) and set the tickets
into `needs_review`.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30461#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