Retrospective on what we said we would do during the Amsterdam meeting (march 2017)
rotating roles
- triage useful / coverity
- hackerone needs people too
- suggestion: try to do trivial tickets yourself instead of opening thousands tickets
onboarding docs/process
- not much progress here
- netwokr team wiki page is useful! same for HACKING dir in tor.git
more anti censorship people
- not much progress here. we need people.
- suggestion: perhaps separate vegas team for anticensorship?
needs more bwauth love
- current project (torflow) sucks: uses old libraries, can't use new libraries because API changed
- several aborted attempts to start a new project
- better & more advanced research designs: peerflow
- new graphs in consensnus health displaying how many relays each bw auth is responsible for (?)
- need testing environment!!!
- longclaw has issues with bw auth: it fills disk
- suggestion: do some work to upgrade the current code to the latest library versions, and bugfixes
- suggestion: take a look at the david/donncha code and see what's going on
- suggestion: put this project on the roadmap
trac / gitlab migration
- we are now using gitlab for code reviews
- qbi disabled new accounts on trac ( we were getting 500 new accounts per hour )
- remark by qbi: They were disabled for a short period of time. Right now people can register, but have to solve a captcha. This keeps away spammers and several people are able to register (I hope this is true for any non-spammer.)
- reach out to other teams so that they also migrate to gitlab (?)
- problem: javascript is mandatory for gitlab (!) but maybe also for the latest trac (?)
- seems to be quite hard to migrate from trac based on behavioral analysis
- how does gitlab work at scale?
- suggestion: use gitlab just for private/secret/security tickets for now? bad. too much stress.
- ticket nr conflicts between gitlab/trac?
- suggestion: assign a new gitlab namespace for ticket numbrs? (all gitlab ticket start with #999xxx so that they dont conflict with trac)
- what are the benefits of gitlab anyway? do we really want to do that?
- we need a staging environment for gitlab, because oniongit has already too much of our data (code reviews)
- suggestion: use gitlab for a specific restricted area of things just for testing over time
- suggestion: ask hiro how much time it will take her to migrate trac to gitlab
- revisit this during the roadmap stage
Last modified 2 years ago
Last modified on Oct 13, 2017, 6:56:08 PM