Note about current insane state change regime.

TODO.txt

@@ -1,4 +1,33 @@
-- Create a PROCESS_STATE_CHANGE_EXITED_UNEXPECTEDLY event.
+- Reconsider the wisdom of sending an event for every process state
+  change.  It's easiest to code this way, but many of the events are
+  useless in a process monitoring system.  Particlarly, nobody will
+  care that a process moved from STARTING to STOPPING or from BACKOFF
+  to STARTING or from STARTING to BACKOFF if we've already notified
+  once.  Nor does anyone care what the starting state is, just the
+  ending state.  Also, the current process state change regime
+  provides no indication of whether the state change that gets
+  reported is "expected".
+
+  The state changes we care about in a monitoring system are these:
+
+  PROCESS_STATE_CHANGE_STOPPED_OR_EXITED (-> STOPPED or -> EXITED)
+
+      PROCESS_STATE_CHANGE_STOPPED (-> STOPPED)
+
+      PROCESS_STATE_CHANGE_EXITED (-> EXITED)
+
+          PROCESS_STATE_CHANGE_EXITED_UNEXPECTED (-> EXITED with an
+          unexpected exit code)
+
+          PROCESS_STATE_CHANGE_EXITED_EXPECTED (-> EXITED with an
+          expected exit code)
+
+  PROCESS_STATE_CHANGE_FATAL (-> FATAL [supervisor gave up trying to start])
+
+  PROCESS_STATE_CHANGE_BACKOFF (-> BACKOFF [supervisor retrying a
+  failed start], but once only probably)
+
+  PROCESS_STATE_CHANGE_RUNNING Process started successfully (-> RUNNING)
 
 - Supervisorctl tab completion and history.
 
@@ -78,8 +107,6 @@
     and fall through.  In an asyncore dispatcher represented by the
     file descriptor, attempt to dispatch the event.
 
-- Fix CVS so not all checkins come from "chrism".
-
 - Support stopping and starting groups in web interface.
 
 - Support operations against both stderr and stdout logs within web