|
|
= Internal Tooling at Tor Project =
|
|
|
''Are the tools we are using working for us?''
|
|
|
|
|
|
Facilitators: gaba, pili, anarcat
|
|
|
|
|
|
Time: 1 hour
|
|
|
|
|
|
'''Goals: '''
|
|
|
|
|
|
1. Review existing tooling vs team requirements
|
|
|
1. 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
|
|
|
|
|
|
1. Issue tracking:
|
|
|
1. trac
|
|
|
1. github
|
|
|
1. gitlab
|
|
|
1. Email
|
|
|
1. Wikis
|
|
|
1. trac
|
|
|
1. gitlab
|
|
|
1. Project Management
|
|
|
1. trac
|
|
|
1. wekan
|
|
|
1. deck
|
|
|
1. gitlab boards
|
|
|
1. Collaborative document editing
|
|
|
1. nextcloud
|
|
|
1. google docs
|
|
|
1. Meeting pads/notes
|
|
|
1. storm
|
|
|
1. etherpad
|
|
|
1. nextcloud
|
|
|
1. Meeting Scheduling
|
|
|
1. doodle
|
|
|
1. Shared calendars
|
|
|
1. nextcloud
|
|
|
1. storm
|
|
|
1. Video/Audio Conference
|
|
|
1. jitsi
|
|
|
1. bluejeans
|
|
|
1. Messaging
|
|
|
1. irc
|
|
|
1. signal
|
|
|
1. keybase
|
|
|
|
|
|
Questions
|
|
|
|
|
|
1. Which categories of tools should be standarized and which tools can be used ad-hoc?
|
|
|
1. Review existing toos at Tor
|
|
|
1. trac
|
|
|
1. google docs
|
|
|
1. sandstorm
|
|
|
1. Toolds under review
|
|
|
1. nextcloud
|
|
|
1. gitlab
|
|
|
|
|
|
Migrations
|
|
|
|
|
|
1. Decision making process
|
|
|
1. 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 |