diff options
Diffstat (limited to 'doc')
-rw-r--r-- | doc/TODO | 23 |
1 files changed, 21 insertions, 2 deletions
@@ -309,8 +309,6 @@ Bugs/issues for Tor 0.2.0.x: o Basic implementation N - Include probability-of-selection R d let bridges set relaybandwidthrate as low as 5kb -R - bug: if we launch using bridges, and then stop using bridges, we - still have our bridges in our entryguards section, and may use them. R - bridge communities . spec . deploy @@ -330,6 +328,27 @@ R - then document the bridge user download timeline. ======================================================================= +For 0.2.1.2-alpha: +R - bug: if we launch using bridges, and then stop using bridges, we + still have our bridges in our entryguards section, and may use them. +R - add an event to report geoip summaries to vidalia for bridge relays, + so vidalia can say "recent activity (1-8 users) from sa". +R - investigate: it looks like if the bridge authority is unreachable, + we're not falling back on querying bridges directly? +R - a getinfo so vidalia can query our current bootstrap state, in + case it attaches partway through and wants to catch up. +R - directory authorities shouldn't complain about bootstrapping problems + just because they do a lot of reachability testing and some of + it fails. +R - if your bridge is unreachable, it won't generate enough connection + failures to generate a bootstrap problem event. +R - if "no running bridges known", an application request should make + us retry all our bridges. +R - get matt to fix vidalia so it moves to a "starting tor" bootstrap + state if it hasn't gotten any status events. Maybe it can even be + more certain by checking the version (<0211) and/or looking at the + results of the getinfo. + For 0.2.1.x: - Proposals to do: - 110: avoid infinite-length circuits |