Opened 2 months ago

Last modified 5 days ago

#30169 new task

Create repos on our infrastructure for TOPL related code

Reported by: gk Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-mobile, tbb-8.5, TorBrowserTeam201905
Cc: igt0, sisbell, sysrqb, hans@…, n8fr8 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We should, now after merging and deploying Tor Onion Proxy Library code (see #27609 and child tickets), get the code onto into our tpo git infrastructure, I think, and create additional user repositories if needed.

So, having some tor-onion-proxy-library repo we use (and for which the github one could be the official upstream) and one for tor-android-service where we can tag and sign releases would be a good start. Not sure if there is more we should consider.

Then we can get changes to any of the new projects treated with our normal code review and commit push process.

We should think about who should have push access to those repos. I think sisbell, sysrqb, and I could be a decent start for that.

Child Tickets

TicketStatusOwnerSummaryComponent
#30337closedtor-gitadmCreate a tor-android-service repositoryInternal Services/Service - git
#30338closedtor-gitadmCreate a tor-onion-proxy-library repositoryInternal Services/Service - git

Change History (4)

comment:1 Changed 7 weeks ago by gk

Keywords: tbb-8.5 added; tbb-8.5-must removed

We can easily start building even though the repo creation is not done (and we don't use the new repos in our tor-browser-build projects).

comment:2 Changed 6 weeks ago by gk

I set up the tor-android-service repo with master pointing to the latest commit we ship in tor-browser-build (i.e. 6a9314aff4418a4edac33ff39fae266b097cf000). And I switched to the tpo repo in commit ea0d9948bcb63cce9612f5a6d6e5cdad5db6561c on tor-browser-build's master (+ I cherry-picked that commit onto maint-8.5 (commit 1f5d05032577524ad2600cc2fb7f28cd2d707256)).

Getting master updated follows the usual procedure. We'll have a bug in Trac that needs to get fixed and if that involves fixes in tor-android-service the respective user-owned tor-android-service repo is used for providing the tor-android-service bits (wherever that is, be it on Gitlab or our own infrastructure). Then the whole gets reviewed and the commit in tor-browser-build gets updated if everything looks good. The ticket then gets closed.

At some point we should think about tagging releases + sign them and use git tags for our maint-* branches (will say stable releases).

comment:3 Changed 5 weeks ago by gk

Keywords: TorBrowserTeam201905 added; TorBrowserTeam201904 removed

Moving tickets to May

comment:4 Changed 5 days ago by gk

Parent ID: #27609
Note: See TracTickets for help on using tickets.