Internal Tooling at Tor Project
Are the tools we are using working for us?
Facilitators: gaba, pili, anarcat
Time: 1 hour
**Goals: **
- Review existing tooling vs team requirements
- Move forward discussions on issues that we have been already discussing:
- email issues
- ticketing system migration to gitlab
- guest accounts
- CI
Materials and Equipment Needed
- papelografos
- sticky notes
Desired Outcome:
- list of what needs to happen before migrating to Gitlab
- list of what needs to happen before migrating to Nextcloud
Resources:
- Migration into gitlab dip discussion
- Document on options for email
Topics that we need to look at
Review existing needs/requirements
- Issue tracking:
- trac
- github
- gitlab
- Wikis
- trac
- gitlab
- Project Management
- trac
- wekan
- deck
- gitlab boards
- Collaborative document editing
- nextcloud
- google docs
- Meeting pads/notes
- storm
- etherpad
- nextcloud
- Meeting Scheduling
- doodle
- Shared calendars
- nextcloud
- storm
- Video/Audio Conference
- jitsi
- bluejeans
- Messaging
- irc
- signal
- keybase
Questions
- Which categories of tools should be standarized and which tools can be used ad-hoc?
- Review existing toos at Tor
- trac
- google docs
- sandstorm
- Toolds under review
- nextcloud
- gitlab
Migrations
- Decision making process
- Migration process
Notes
Services currently running
git.tpo - kind of maintained
rt - currently unmaintained, steph uses that for press queries, donation queries; big spam problem; steph is looking at it new messages relgularly; unmaintained
storm - currently unmaintained
blog is fine but blog template is usually breaking with drupal update; Converting to lektor? If so, we would not have comments. Maybe using Discourse or something else?
Potentially new services
NextCloud
- opening a document in onlyoffice takes longer than storm
- asking people for feedback in august to help with a decision migration plan
- OnlyOffice issues:
- word count?
- tagging comments?
- Should we migrate svninternal/corporate svn? And if so, how?
- Uptime requirements for Sue?
- Concrete plan on what is going into Nxtclound and what not and how this should be exposed?
- having a unified platform for everything (calendar etc.) is pretty worthwhile taking into account what we have today
- Linus is asking nextclound testers in August for feedback to make a decision in September on how to move on
We should generally build a guide for secure, private, and public stuff organization-wide
Gitlab
- network-team: moving to Gitlab is okay, still accepting pull requests on Github
- anarcat is summarizing the anonymous/guest account session
- having Gitlab helps porting software to *bsds (Gitlab API is useful here)
- Blockers:
- Trac queries and wikis?
- CI integration (Travis hooks, Appveyor etc.)? You are able to hook up runners from anywhere and scope them permisson-wise
- Dozens of other small Tor projects could be a good target first before dealing with the larger projects like tor and Tor Browser
- maintainership of Gitlab projects is more fine-grained/trickle down fashion than gitolite (who makes sure configuration is not rotting?)
- Do we have someone being able to scan for permission anomalies (yes, it could be some project admin)
- gitolite permissions should be able to get replicated in gitlab
- decentralized versions of access control does work better than centralized ones as the groups know better about themselves than a central entity
- all in all there are no real blockers for the gitlab transition
- we need to come up with a ticket migration plan
- maintenance cost
- running Gitlab ourselves is not cheaper than outsourcing it
- there will be a maintenance cost which is currently not clear
- push access only in one direction
Email update
- issue with providers like Google which is just not delivering emails from torproject.org
- anarcat summarizes the current state of the discussion