[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[or-cvs] r15249: a huge pile of bridge and bootstrap related bugs that arma s (tor/trunk/doc)



Author: arma
Date: 2008-06-14 02:04:16 -0400 (Sat, 14 Jun 2008)
New Revision: 15249

Modified:
   tor/trunk/doc/TODO
Log:
a huge pile of bridge and bootstrap related bugs that arma should work on.


Modified: tor/trunk/doc/TODO
===================================================================
--- tor/trunk/doc/TODO	2008-06-14 05:14:57 UTC (rev 15248)
+++ tor/trunk/doc/TODO	2008-06-14 06:04:16 UTC (rev 15249)
@@ -309,8 +309,6 @@
     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 @@
 
 =======================================================================
 
+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