--- a/README.txt	Fri Dec 30 16:27:14 2011 -0800
+++ b/README.txt	Tue Jul 31 09:49:57 2012 -0700
@@ -33,14 +33,14 @@
 
 You can create a master-slave pair by running ``create-autobot`` after
 activating the virtualenv. This is mostly useful for autobot
-development. The scripts ``create-autobot-master`` and 
+development. The scripts ``create-autobot-master`` and
 ``create-autobot-slave`` are also available and are more useful for
 production, as normally you will not want to keep the master and the
 slave on the same machine except for development and testing.  The
 scripts will prompt you for a factory or you can specify one or more
 from the commandline using ``--factory`` or ``-f``. The factories are
 from ``autobot.projects`` and its subdirectories.  You can list the
-available factories with ``create-autobot --list-factories`` (or 
+available factories with ``create-autobot --list-factories`` (or
 ``create-autobot-master --list-factories``).
 
 Running ``create-autobot --help`` will give the variables you can set
@@ -52,11 +52,11 @@
 your particular bot.  You can change these in the resultant
 configuration later.
 
- 
+
 Using autobot
 -------------
 
-The buildmaster and buildslave are started with 
+The buildmaster and buildslave are started with
 ``buildbot start master`` and ``buildslave stop slave`` from the bot's
 directories. Respective ``stop`` commands also exist.  If you used the
 ``create-autobot`` command the generated bot will have a
@@ -111,7 +111,7 @@
 * pollInterval: how often to poll the repositories, in seconds [DEFAULT: 60]
 * treeStable: how long to wait before the tree settles down before
   building [DEFAULT: 60]
-  
+
 The other defaults may be seen by running ``create-autobot-master --help``.
 
 Other parameters given in the ``[:master:]`` section are used as the
@@ -128,13 +128,13 @@
 
 * factories: space-separated list of factories to run on that slave.
   If the special value ``*`` is used, all factories will be run.  You
-  can view the factories available with 
+  can view the factories available with
   ``create-autobot --list-factories``. The factory name corresponds to
   the directory (or module) name in ``autobot.projects``.  If
   every slave is meant to run the same factories, you can put this in
   the ``:master:`` section
 
-* os: the operating system of the slave. Should be one of ``linux``, 
+* os: the operating system of the slave. Should be one of ``linux``,
   ``win``, or ``mac`` (though see TODO about future use of MozInfo
   making this obselescent). You probably *shouldn't* have a default
   key for this in the ``:master:`` section (though autobot won't try
@@ -145,7 +145,7 @@
 factory sections:  All other sections are used to build the factories.
 Each parameter in a factory section is used as a constructor
 (``__init__``) keyword argument when they are created in the
-``master.cfg``. So a factory section like:: 
+``master.cfg``. So a factory section like::
 
  [foo]
  bar = fleem
@@ -168,16 +168,18 @@
 
 What does autobot test?
 
+* mozbase        [WORKING]
 * logparser      [WORKING]
 * profilemanager [IN FLIGHT]
 * mozmill        [IN FLIGHT]
 * devicemanager  [IN FLIGHT]
 * firebug        [TODO]
 * jetpack        [TODO]
+* talos          [TODO]
 
 The projects are obtained from any factories in subdirectories of
-``autobot.projects`` (use 
-``python -c 'from autobot import projects; print projects.__file__'`` 
+``autobot.projects`` (use
+``python -c 'from autobot import projects; print projects.__file__'``
 to see this location).
 
 
@@ -188,7 +190,7 @@
 for specifying sources.  Sources live as a member on the instance, named
 (oddly) ``sources``.  This is a dict with the key being the source
 type and the value being the source to use.  Source types are
-currently "git" and "hg", though this is easily extensible.  
+currently "git" and "hg", though this is easily extensible.
 
 Internally, an individual source is stored as a 2-tuple with the first
 item being the URL of the source and the second item being the
@@ -245,7 +247,7 @@
   ``master.cfg`` looks in each factory and gleems its needed
   repository from its ``sources`` attribute (if any) in the internal
   storage mechanism of ``SourceFactory`` and sets up schedulers
-  accordingly. 
+  accordingly.
 
 * ``VirtualenvFactory``: inherits from ``SourceFactory``. creates a
   python virtualenv and provides build properties ``%(virtualenv)s``,
@@ -261,8 +263,8 @@
   ``%(python)s setup.py install``)
 
 * ``FirefoxDownloaderFactory``:  downloads and unpacks a Firefox
-  bundle, using 
-  `GetLatestTinderbox <http://hg.mozilla.org/automation/getlatest-tinderbox>`_ . 
+  bundle, using
+  `GetLatestTinderbox <http://hg.mozilla.org/automation/getlatest-tinderbox>`_ .
   It also provides three properties: ``%(firefox_url)s``,
   ``%(firefox_bundle)s``, and ``%(firefox)s`` -- the last, and most
   interesting, being the absolute path to the Firefox executable. You
@@ -306,6 +308,8 @@
   brasstacks test server. you can omit the restserver keyword, it will
   use the correct default if you skip it
 
+* email notifications
+
 * get FirefoxDownloaderFactory working on Mac with .dmg files!
 
 * singular checkout of repos on slaves: the slaves should have a
@@ -313,4 +317,4 @@
   branch pair.  It is then updated as the slaves need and (e.g.)
   cloned from there.  This should effectively minimize fetch time.
 
-* use MozInfo package
+* use MozInfo package for slave information