Implement info command, also refactoring.

[wizard.git] / TODO

diff --git a/TODO b/TODO
index e309fdb66b747a84fe4122c8aad95d1d26a9621a..36bcead79c3c58407f716d5227120db875d2353c 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,5 +1,12 @@
 The Git Autoinstaller
 
+TODO NOW:
+
+* Migrate and upgrade the lone mediawiki-1.5.6 install
+* Create the migration script
+
+OVERALL PLAN:
+
 * Some parts of the infrastructure will not be touched, although I plan
   on documenting them.  Specifically, we will be keeping:
 
@@ -18,7 +25,7 @@ The Git Autoinstaller
 
     2. Download the new tarball
 
-    3. Extract the tarball over the working copy
+    3. Extract the tarball over the working copy (`cp -R a/. b` works well)
 
     4. Check if there are any special update procedures, and update the
        .scripts/update shell script as necessary (this means that any
@@ -29,7 +36,7 @@ The Git Autoinstaller
     X. Check for empty directories and add stub files as necessary
        (use preserve-empty-dir)
 
-    5. Commit your changes, and tag as v1.2.3-scripts1
+    5. Commit your changes, and tag as v1.2.3-scripts
 
     6. Run the "dry-run script", which uses Git commands to check how many
        working copies apply the change cleanly, and writes out a logfile
@@ -40,11 +47,37 @@ The Git Autoinstaller
 
     8. Run the "deploy" script, which applies the update to all working
        copies possible, and sends mail to users to whom the working copy
-       did not apply cleanly.
+       did not apply cleanly. (It also frobs .scripts/version)
 
     Note: The last three scripts will need to be implemented, with an
           eye towards speed.
 
+* How to migrate an old autoinstaller to the new autoinstaller
+
+    - Find the oldest tarball/patch set for the application that still
+      is in use and upgradable.
+
+    - Untar, apply patch, place in a directory (unfurl) and git init
+
+    - Commit this as the "pristine" version (branch "pristine")
+
+    - Apply scripts patches
+
+    - Create the .scripts directory and populate it with the interesting
+      information (see below)
+
+    - Commit this as the "scripts" version (branch "master")
+
+* How to update the autoinstaller repository
+
+    - Checkout pristine branch
+    - Delete contents of pristine branch (excluding .git, try rm -Rf * and remove stragglers)
+    - Unfurl tarball
+    - Commit as new pristine branch
+    - Checkout scripts branch
+    - Merge pristine branch
+    - Fix as necessary
+
 * The repository for a given application will contain the following files:
 
     - The actual application's files, as from the official tarball
@@ -55,30 +88,39 @@ The Git Autoinstaller
           which performs the commands necessary to update a script.  This can
           be in any language.
 
-        * .scripts/version which contains the version last autoinstalled
-          (as distinct from the actual version the script is)
-
-        * .scripts/real-version (+x) which checks the source code to find the
-          actual version of the application
-
         * .scripts/.htaccess to prevent this directory from being accessed
           from the web.
 
+        * .scripts/database (generated) contains the database the
+          user installed the script to, so scripts-remove can clean it
+
+        * .scripts/version (generated) which contains the version
+          last autoinstalled (as distinct from the actual version
+          the script is) (This is the same as .scripts-version right
+          now; probably want to keep that for now)
+
     - Because there will be no .gitignore file, you *must not* run
       `git add .` on an actual running copy of the application.
-      `git add -u .` will generally be safe.
+      `git add -u .` will generally be safe, but preferred mode
+      of operation is to operate on a clean install.
 
 * The migration process shall be as such:
 
     1. git init
 
-    2. git add remote origin /foo
+    2. git remote add origin /foo
 
-    3. whatever the merge frob is
+    3. git config branch.master.merge refs/heads/master
 
     4. git fetch origin
 
-    5. git reset
+    5. git reset v1.2.3-scripts
+
+    5. git checkout .scripts
+
+    6. Setup .scripts/version (probably pipe the output of real-version)
+        UNCLEAR if this is a good thing; if it is, make sure we add
+        a .gitignore to the .scripts directory
 
 * We will not add special code to handle .htaccess; thus the kernel patch
   for allowing Apache access to .htaccess sent to scripts-team@mit.edu
@@ -86,8 +128,15 @@ The Git Autoinstaller
 
 * The autoupgrade shall be the process of:
 
+    # Make the directory not accessible by the outside world (htaccess, but be careful!)
     git add -u .
     git commit -m 'automatically generated backup'
-    git pull /mit/scripts/deploy/wordpress.git master
+    git pull origin master
     if [ $? ne 0 ]; then git reset --hard; echo 'conflicts during upgrade'; fi
     ./.scripts/update
+    # Make it accessible
+
+  (with some more robust error checking)
+
+* Make install-statistics generate nice pretty graphs of installs by date
+  (more histograms, will need to check actual .scripts-version files.)