give proposal 151 a changelog and other touchups

ChangeLog

@@ -1,5 +1,17 @@
-Changes in version 0.2.2.2-alpha - 2009-09-??
+Changes in version 0.2.2.2-alpha - 2009-09-17
   o Major features:
+    - Tor now tracks how long it takes to build client-side circuits
+      over time, and adapts its timeout to local network performance.
+      Since a circuit that takes a long time to build will also provide
+      bad performance, we get significant latency improvements by
+      discarding the slowest 20% of circuits. Specifically, Tor creates
+      circuits more aggressively than usual until it has enough data
+      points for a good timeout estimate. Implements proposal 151.
+      We are especially looking for reports (good and bad) from users with
+      both EDGE and broadband connections that can move from broadband
+      to EDGE and find out if the build-time data in the .tor/state gets
+      reset without loss of Tor usability. You should also see a notice
+      log message telling you that Tor has reset its timeout.
     - Authorities can now vote on arbitary integer values as part of the
       consensus process. This is designed to help set network parameters.
       Implements proposal 167.

src/or/circuitbuild.c

@@ -179,7 +179,7 @@ circuit_build_times_add_time(circuit_build_times_t *cbt, build_time_t time)
     cbt->total_build_times++;
 
   if ((cbt->total_build_times % BUILD_TIMES_SAVE_STATE_EVERY) == 0) {
-    /* Save state every 100 circuit builds */
+    /* Save state every n circuit builds */
     if (!unit_tests && !get_options()->AvoidDiskWrites)
       or_state_mark_dirty(get_or_state(), 0);
   }

src/or/or.h

@@ -2882,7 +2882,7 @@ void entry_guards_free_all(void);
 /** Width of the histogram bins in milliseconds */
 #define BUILDTIME_BIN_WIDTH ((build_time_t)50)
 
-/** Cuttof point on the CDF for our timeout estimation.
+/** Cutoff point on the CDF for our timeout estimation.
  * TODO: This should be moved to the consensus */
 #define BUILDTIMEOUT_QUANTILE_CUTOFF 0.8