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 :)