Update README and TODO.

[wizard.git] / TODO

diff --git a/TODO b/TODO
index 79de13564d6fc7b5d3b569a1db577b2ebc132374..0cb9ebc3e4751a374991ada52e115ff7274184f9 100644 (file)
--- a/TODO
+++ b/TODO
@@ -2,20 +2,24 @@ The Git Autoinstaller
 
 TODO NOW:
 
-- Consider adding user config to repository
-- Put php.ini links in repos (probably will need another
-  script in .scripts)
-- Version configuration
-
-- Consider making usermode wizard operation a support mode
-  (mostly for letting users upgrade things themself)
+- Better error message if daemon/scripts-security-upd
+  is not on scripts-security-upd list
 
 - Add repository flag to migrate so that we can specify an
   arbitrary repository to migrate to
 
+- Build automation for generating config files; this automation
+  will be shared with the migrate script and the installer script
+  (migrate script needs to be able to pull out values from config
+  file, so will we; installer script needs to be able to run
+  the installer to generate config files, so will this)
+
 - The great initial deploy:
     - Turn on mediawiki new autoinstaller
-    - Migrate all mediawik installs
+    - Migrate all mediawiki installs
+
+- Consider making usermode wizard operation a support mode
+  (mostly for letting users upgrade things themself)
 
 - Implement proper deploy log parsing; this basically means we
   need to be able to introspect Git Log. Consider using git-python
@@ -28,6 +32,7 @@ TODO NOW:
   its latest version (do this after its migration)
 - Wordpress needs to check for php.ini files (which it almost
   certianly has) and commit messages
+- Wordpress needs user config and php.ini links made
 
 - Summary script should be more machine friendly, and should not
   output summary charts when I increase specificity
@@ -37,10 +42,8 @@ TODO NOW:
 
 PULLING OUT CONFIGURATION FILES IN AN AUTOMATED MANNER
 
-advancedbook: Two template files to fill out
 advancedpoll: Template file to fill out
 django: Noodles of template files
-e107: Multistage install process
 gallery2: Multistage install process
 joomla: Template file
 mediawiki: One-step install process
@@ -50,6 +53,37 @@ trac: NFC
 turbogears: NFC
 wordpress: Multistage install process
 
+PHILOSOPHY ABOUT LOGGING
+
+Logging is most useful when performing a mass run.  This
+includes things such as mass-migration as well as when running
+summary reports.  An interesting property about mass-migration
+or mass-upgrade, however, is that if they fail, they are
+idempotent, so an individual case can be debugged simply running
+the single-install equivalent with --debug on.  (This, indeed,
+may be easier to do than sifting through a logfile).
+
+It is a different story when you are running a summary report:
+you are primarily bound by your AFS cache and how quickly you can
+iterate through all of the autoinstalls.  Checking if a file
+exists on a cold AFS cache may
+take several minutes to perform; on a hot cache the same report
+may take a mere 3 seconds.  When you get to more computationally
+expensive calculations, however, even having a hot AFS cache
+is not enough to cut down your runtime.
+
+There are certain calculations that someone may want to be
+able to perform on manipulated data.  As such, this data should
+be cached on disk, if the process for extracting this data takes
+a long time.  Also, for usability sake, Wizard should generate
+the common case reports.
+
+Ensuring that machine parseable reports are made, and then making
+the machinery to reframe this data, increases complexity.  Therefore,
+the recommendation is to assume that if you need to run iteratively,
+you'll have a hot AFS cache at your fingerprints, and if that's not
+fast enough, then cache the data.
+
 COMMIT MESSAGE FIELDS:
 
 Installed-by: username@hostname