Juga's email with a list of things we should discuss:
(1) create a component in trac called sbws? yes we should. tim will. tim did.
(2) what should we do with the dirauth component? answer: tor code changes go in tor, sbws changes go in sbws, tasks for directory auth operators go in dirauth component. [juga: updated https://trac.torproject.org/projects/tor/wiki/org/process/TorOnTrac]
(3) Milestones for sbws with a date? A good task for this breakout session.
(4) How to best annotate tickets that make progress on sbws? Having a trac ticket that has a list of all the work is a great idea. Same with a github milestone. But we need to choose.
Todo: choose trac vs github for issue tracking.
[juga: what has been decided?]
(5) There are tickets that are bwauth related, but are poorly sorted. tor-bwauth is the keyword that tim recommends. (tor-dirauth is for changes to the tor program, which is different.) [juga: updated https://trac.torproject.org/projects/tor/wiki/org/process/TorOnTrac If it's fine then, i'll add the keyword "tor-bwauth" to whatever is related to bwauths. Can we actually do a batch-modify that?]
Pastly has a spreadsheet of trac tickets that he has triaged: https://docs.google.com/spreadsheets/d/1shkfChCPb-UmwOMHybSQHgEahL50mEynoXK0W82owjA/edit#gid=0 [juga: what is the query made to choose those tickets?]
Roger mentions having moria1 include bwscanner versions in its votes. Tim points to https://trac.torproject.org/projects/tor/ticket/3723 Roger thinks there is another ticket that should probably be merged with that one.
Discussion topics here:
Trac vs github for issue tracking? Tim points out that the network team uses trac, so if you want to be integrated in the network team, that's where they'll expect it to be.
[juga: for work on the Tor specs or little-t-tor, it should be in trac. What about sbws work? (see 4)]
We have a spec, which tells us what should be in the v3 bandwidth file. How close is sbws to outputing this format?
- There's some simple bug that needs fixing about outputing the first line correctly: the timestamp should be about the most recent measurement in the file, not the time that we wrote the file.
Minimum viable product steps:
- Timestamp spec bug fix.
- Max Advertised Bandwidth hack.
[juga: which are the related tickets or discussions?] - Check that the scaling is working. [juga: create ticket for this?, which are the steps thought to check this?, tjr's scripts?]
- Get one dir auth running it (maybe that's tjr).
- Add tls-verify option so users can decide how to handle certs at the destination
Four bw auths:
- Two debian, one Ubuntu, one RHEL 6.
Things pastly wants:
- A stem alpha deb
- Get juga to make a deb for sbws and get it on torproject.org (which involves getting it into debian sid first). [juga: apparently it's preferred that packages in tpo are also in official Debian archive so that they have less risk to become un-maintained, but i guess that's up to whoever decides what goes to tpo debian archive]
Question for network team:
- Does the network team want to support old sbws versions in Debian stable? Or should we file a bug in Debian sid [juga: last discussions pointed that this type of question should be for dirauth operators. In any case:
- there aren't sbws old versions yet
- new sbws versions might be wanted to run in ("old") stable Debian, i can backport it to it
- new Debian packages start in Debian sid and take 1/2 years to be in stable (unless doing backports)]