Matt Traudt
2018-04-19 22:50:57 UTC
Next meeting is scheduled 26 April 2018 at 2200 UTC in #tor-meeting,
**BUT** we are probably going to look into finding a time that works
better across three halves of the globe.
Pad is here, and is copy/pasted below. https://pad.riseup.net/p/BenwGdgpz0uS
Meeting IRC log
http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-04-19-21.59.log.html
Simple Bandwidth Scanner meeting 19 April 2018
==============================================
Previous weeks notes:
https://lists.torproject.org/pipermail/tor-dev/2018-April/013059.html
Updates
--------------------------------------------------------
pastly:
- Started running an authority in the test net. Don't think it's
working yet
and/or people have started trusting it
- Switched to standard python logging module
- Added periodic reachability tests for helper relays
- (Helped) add FAQ and glosasry to docs
- Learned: no part of sbws is CPU bound. Weird results were due to a
helper
that is not capable of much bandwidth
- Time is still passing. In less than 2w the open source paperwork
should be back
next week:
- Put docs on an onion service
- Ask dirauths what they want to do about sbws servers
In the coming weeks, I think I need to be transitioning away from "big"
feature
type stuff that isn't absolutely necessary, and instead focus my time on
docs,
tests, and making sbws easy to use.
I think literal next steps need to include a practice deployment and
transition in the testnet.
It's one thing to run an sbws scanner and server. I've done that. I want
to see other people try
it so we can learn what isn't obvious to anyone but me. I want to
exercise getting scan results to
the dirauth so it can put them in the consensus.
i've tried scanner and server and reported problems :)
* list tasks for next months: https://pad.riseup.net/p/bfikl6PM0YV9
* plan proposed by teor with testnet deployment:
* ...
* it'll be very useful to have sbws doc public!
juga:
last week:
* 1st draft spec
* setup dirauth, sbws server, sbws scanner
* dirauth not yet in consensus
* start doc about what we have deployed so far (started to feel a
bit lost about what we have/need)
* added draft faq and glossary to doc
next week:
* finish spec
* check the status of config files vs cli args, with debug (sorry
pastly, didn't follow close the changes) and see whether #91 is really
needed
* check the status of tests/chutney
* implement actually some unit test?
* think how to make easier deployment at some point and add
something on it? (cron/Makefile/system services?)
questions:
* pastly: once sbws repo is public, can we work on new releases
publicly? [pastly: says yes]
teor:
last week:
* occasional suggestions
this week:
* make my test dirauth a trust pastly's and juga's dirauths
* eventually try to set up sbws on the testnet
**BUT** we are probably going to look into finding a time that works
better across three halves of the globe.
Pad is here, and is copy/pasted below. https://pad.riseup.net/p/BenwGdgpz0uS
Meeting IRC log
http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-04-19-21.59.log.html
Simple Bandwidth Scanner meeting 19 April 2018
==============================================
Previous weeks notes:
https://lists.torproject.org/pipermail/tor-dev/2018-April/013059.html
Updates
--------------------------------------------------------
pastly:
- Started running an authority in the test net. Don't think it's
working yet
and/or people have started trusting it
- Switched to standard python logging module
- Added periodic reachability tests for helper relays
- (Helped) add FAQ and glosasry to docs
- Learned: no part of sbws is CPU bound. Weird results were due to a
helper
that is not capable of much bandwidth
- Time is still passing. In less than 2w the open source paperwork
should be back
next week:
- Put docs on an onion service
- Ask dirauths what they want to do about sbws servers
In the coming weeks, I think I need to be transitioning away from "big"
feature
type stuff that isn't absolutely necessary, and instead focus my time on
docs,
tests, and making sbws easy to use.
I think literal next steps need to include a practice deployment and
transition in the testnet.
It's one thing to run an sbws scanner and server. I've done that. I want
to see other people try
it so we can learn what isn't obvious to anyone but me. I want to
exercise getting scan results to
the dirauth so it can put them in the consensus.
i've tried scanner and server and reported problems :)
* list tasks for next months: https://pad.riseup.net/p/bfikl6PM0YV9
* plan proposed by teor with testnet deployment:
* ...
* it'll be very useful to have sbws doc public!
juga:
last week:
* 1st draft spec
* setup dirauth, sbws server, sbws scanner
* dirauth not yet in consensus
* start doc about what we have deployed so far (started to feel a
bit lost about what we have/need)
* added draft faq and glossary to doc
next week:
* finish spec
* check the status of config files vs cli args, with debug (sorry
pastly, didn't follow close the changes) and see whether #91 is really
needed
* check the status of tests/chutney
* implement actually some unit test?
* think how to make easier deployment at some point and add
something on it? (cron/Makefile/system services?)
questions:
* pastly: once sbws repo is public, can we work on new releases
publicly? [pastly: says yes]
teor:
last week:
* occasional suggestions
this week:
* make my test dirauth a trust pastly's and juga's dirauths
* eventually try to set up sbws on the testnet