[tor-dev] Bandwidth Scanning Meeting Notes 3 May 2018

[Matt Traudt]

Next meeting is 10 May 2018 at 1200 UTC for 30 minutes... maybe. While
we should find a standard time, next week is a special case for pastly
and teor.

Notes are https://pad.riseup.net/p/ioYq89yZSx1t and copy/pasted below.

---------------------------------------------------------------------

This pad:
    https://pad.riseup.net/p/ioYq89yZSx1t

Meetbot log:

http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-05-03-09.29.html

Last week

    https://lists.torproject.org/pipermail/tor-dev/2018-April/013108.html


Next Milestone:
    1st Status Update: May 25th

All Milestones:
    https://trac.torproject.org/projects/tor/wiki/doc/gsoc


######################## Updates

pastly:
    - Make significant strides towards the switch to HTTP/S
    - sbws launches Tor for itself
    - started tagging and icrementing and signing versions


teor:
    - reviewed the bandwidth format spec
    - feedback on tor bwfile tests and bug fixes
    - feedback on sbws / tor launching
    - the sbws vs torflow averages in the testnet are stable and consistent
    - fixed a buffer read-past-the-end when the file can't be read in
the bwfile parsing code


juga:
    Last week:
        * sbws:
            * Worked on "Add what to include in a source distribution"
(issues/132)
            * Discussed with pastly about "Include file where to write
``generate`` results in the config?"
            * Created "Fix version, prepare for future release"
(issues/131): pastly started to tag versions, what is needed for
packaging/distributing sbws (whatever the method will be)
            * Worked on "Include software and sofware_version headers"
(issues/96), waiting to finish the spec so that we don't keep switch format
            * Worked on "Add useful information in sbws header lines"
(issues/119): PR 130 waiting to finish spec
        * spec:
            * Worked with teor on the new version sent to @tor-dev
        * little-tor:
            * Worked on "Allow additional header lines" (#25960): also
waiting for the specs
            * Started to write tests for the previous and "Create unit
test for dirserv_read_measured_bandwidths" (#25947)
    Next week:
        * spec: wait for comments and change according to it
        * little-tor:
            * continue with #25960 (when spec ready)
            * finish #25947, tests for current code, additional header
lines
              and possible refactor
        * sbws: work on 96, 119 when spec is ready



######################## Discussions

-------------- sbws logo offer??

Is this something we care about?

Decision: not really, but ux might like the help

-------------- Meeting time

0930 UTC is terribly early for pastly, but he can do it in the name of
collab.
1130 UTC would actually be easier for teor, but that's about as late as
they can go
For juga both times are fine ^
Decision: from 12:00 to 12:30 UTC

Decision: 1200 UTC and only 30m long next week

-------------- Bandwidth spec

Bugfixes and incremental improvements, or a rewrite?
Should i create a new version, include the changes or wait for more
comments?

Decision: make minor changes if there is time

-------------- Bandwidth file parsing code in Tor

unit tests are ok
bugfixes are ok
What this mean? ^

we can always do tests and bugfixes

If we implement the format, we might have to change it

-------------- Bandwidth file generation

If we implement the format, we might have to change it
pastly thinks he/we can easily handle whatever crazy thing you all come
up with for the Tor side of code as long as it follows the general idea
of one-line-per-relay, simple integers, and maybe a header with some
metadata
juga thinks there is not crazy thing, and parsing strings in python is
way easier than c :)