Remove cruft from aforementioned document.

doc/testing.txt

@@ -97,70 +97,3 @@ Notes on testing.
 
   Generating your own copy of the DB needs to be addressed.
 
-  
-
-
-My approach is intended to minimize the number of scripts that need to
-be run through configure rewritting to get the --prefix argument into
-them. I also want to enable testing from private install trees.  We
-also need to minimize security risks, so we can't use an environment
-variable of course, since we have a number of setuid scripts that
-cannot be invoking sub programs based on a path in an environment
-variable. Anyway, here is my rundown.
-
-* People test their own stuff by installing and running from thier
-  prefix directory. This is not as convenient as running out of your
-  source directory, but its the only workable solution that provides a
-  reasonable testing harness that looks like the real thing, and will
-  allow you to do testing with your own versions of things.
-
-* We use a --prefix directory. It defaults to /usr/testbed/. This
-  implies we start using configure. Other configurable items we need
-  to consider are the name of the DB and the paths in the web page
-  stuff so that we can test diffferent versions of the pages, using
-  different versions of the DB, etc.
-
-* All user executable "front end" programs should be installed to
-  ${PREFIX}/bin. (ex: tbrun, tbend). This is a flat directory.
-
-* All admin executable "front end" programs should be installed to
-  ${PREFIX}/sbin. (ex: os_load, nalloc, tmcd). This is a flat directory.
-
-* All of the other backend support stuff from tbsetup and other places
-  go into ${PREFIX}/libexec. This directory can have subdirs. The ir
-  parsing stuff, support perl/tcl libraries, etc.
-
-* Configuration files go into ${PREFIX}/etc. (ex: pxe).
-
-* There are no hardwired paths in the scripts. Any script that needs
-  to access another testbed program or library has to be rewritten by
-  configure. Something like this in "script.in" which will get
-  rewritten as "script"
-
-  $TBROOT = @TBROOT@;
-  $ENV{'PATH'} = "$TBROOT/bin:$TBROOT/sbin:...";
-  $handle_ip = "$TBROOT/libexec/ir/handle_ip";
-
-* DB name (tbdb). Same for the DB name. 
-
-* We rewrite www/defs.php3 with config, much as I do know for testing
-  on my home machine. This way, we can all share the web server,
-  running individual versions of the web pages. Your version of the
-  web pages can either operate on the real DB, or on your own private
-  version of the DB (say, tbdb-lbs) which you can create with
-  mysqldump for testing.
-
-* Even though the name of the DB is not hardwired in, there are still
-  problems with this approach, like allocating machines from your DB
-  that are already allocated in the real DB! We can probably solve
-  this with a little trick; reserve some nodes in the real testbed DB,
-  and reduce the number of nodes in your private DB to exactly that
-  set.
-
-* What about things like snmpit? Well, you gotta test that out using
-  the real switches. As long as you can test it from your own
-  directory, and with a set of nodes reserved out of the testbed DB,
-  it should be mostly safe. Use caution though.
-
-* Other cases like the above?
-