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