decide that messing with fallback-concensus for 0.2.0.10-alpha

isn't worth it. also mention bug 546 again.

svn:r12432

diff --git a/doc/TODO b/doc/TODO
index 4ca3f0758dcd5e94095cd553b3d7e6bb884d8e18..99bfe5a9d4742e31e3626b970d87bc0647d63a71 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -15,6 +15,7 @@ J       - Jeff claims
         X Abandoned
 
 Items blocking 0.2.0.10-alpha:
+  - Some resolution for (the reopened) bug 546.
   - We should back out the MBTF->WFU Guard factors, since they open us
     up to new attacks, and don't this "median" notion doesn't necessarily
     help us distinguish between "was good enough to be a guard when
@@ -31,20 +32,14 @@ Here's a go:
   median WFU of the set. In addition, anybody born more than a month ago
   who has >=50% WFU is always a winner.
 
-  - Should we ship with a fallback-consensus? Where in the tarball does
-    it go? What's the process for choosing it?
-    - We can, but we don't have to now.  Stick it in place of the
-      empty fallback-consensus file in src/config if you like. -NM
-    - To choose, just grab the most recent consensus you have. -NM
-
   - If 1.5*MaxCircuitDirtiness is more than KeepAlive, do we then send
     a KeepAlive and reset our timeout, thus never reaching 1.5*MCD?
     - Aw, crud.  We could keep track of how long it's been since
       we last did anything _other_ than a keepalive, I guess. -NM
 
-  o "When reporting clock skew, and we only have a lower bound on
-    the amount of skew, amount anyway, marked as a lower bound.
-    [XXX Nick: what does this mean??]"
+For Tor 0.2.0.11-alpha:
+  - Put a consensus in place of the empty fallback-consensus file in
+    src/config and see what breaks.
 
 
 Things we'd like to do in 0.2.0.x: