-- 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)
-
-- Add repository flag to migrate so that we can specify an
- arbitrary repository to migrate to
-
-- The great initial deploy:
- - Turn on mediawiki new autoinstaller
- - Migrate all mediawik installs
-
-- Implement proper deploy log parsing; this basically means we
- need to be able to introspect Git Log. Consider using git-python
- for this. There's also missing functionality, bad error handling
- and hacks in the prototype implementation of upgrade
-
-- Wordpress needs to have .scripts dir in all -scripts versions
- (remember --no-walk!) (also make .scripts/.htaccess)
-- Wordpress needs to have a .scripts/update script written for
- its latest version (do this after its migration)
-- Wordpress needs to check for php.ini files (which it almost
- certianly has) and commit messages
-
-- Summary script should be more machine friendly, and should not
- output summary charts when I increase specificity
-- Check how many autoinstalls are missing w bits for
- daemon.scripts (this would need pyafs)
-- Consider fixing Wizard's commit messages
+- Keep my sanity when upgrading 1000 installs
+ - Distinguish between errors(?)
+ - Custom merge algo: absolute php.ini symlinks to relative symlinks (this
+ does not seem to have been a problem in practice)
+ - Custom merge algo: check if it's got extra \r's in the file,
+ and dos2unix it if it does, before performing the merge
+ - `vos exa` in order to check what a person's quota is. We can
+ figure out roughly how big the upgrade is going to be by
+ doing a size comparison of the tars: `git pull` MUST NOT
+ fail, otherwise things are left conflicted, and not easy to fix.
+ - Prune -7 call errors and automatically reprocess them (with a
+ strike out counter of 3)--this requires better error parsing
+ - Report stats if I C-C the process
+
+- Distinguish from logging and reporting (so we can easily send mail
+ to users)
+ - Figure out a way of collecting blacklist data from .scripts/blacklisted
+ and aggregate it together
+ - Failed migrations should be wired to have wizard commands in them
+ automatically log to the relevant file. In addition, the seen file
+ should get updated when one of them gets fixed.
+ - Failed migration should report how many unmerged files there are
+ (so we can auto-punt if it's over a threshold)
+
+- Let users use Wizard when ssh'ed into Scripts
+ - Make single user mass-migrate work when not logged in as root
+
+- Make the rest of the world use Wizard
+ - Make parallel-find.pl use `sudo -u username git describe --tags`
+ to determine version. Make parallel-find.pl have this have greater
+ precedence. This also means, however, that we get
+ full mediawiki-1.2.3-2-abcdef names (Have patch, pending testing and commit)
+ - Make deployed installer use 'wizard install' /or/ do a migration
+ after doing a normal install (the latter makes it easier
+ for mass-rollbacks).
+
+- Pre-emptively check if daemon/scripts-security-upd
+ is not on scripts-security-upd list (/mit/moira/bin/blanche)
+
+- Redo Wordpress conversion, with an eye for automating everything
+ possible (such as downloading the tarball and unpacking)
+
+- Pay back code debt
+ - Genericize callAsUser and drop_priviledges in shell
+ - Summary script should be more machine friendly, and should not
+ output summary charts when I increase specificity
+ - Summary script should do something intelligent when distinguishing
+ between old-style and new-style installs
+ - Report code in wizard/command/__init__.py is ugly as sin
+
+- Other stuff
+ - Don't use the scripts heuristics unless we're on scripts with the
+ AFS patch. Check with `fs sysname`
+ - Make 'wizard summary' generate nice pretty graphs of installs by date
+ (more histograms, will need to check actual .scripts-version files.)
+ - It should be able to handle installs like Django where there's a component
+ that gets installed in web_scripts and another directory that gets installed
+ in Scripts.
+ - ACLs is a starting point for sending mail to users, but it has
+ several failure modes:
+ - Old maintainers who don't care who are still on the ACL
+ - Private AFS groups that aren't mailing lists and that we
+ can't get to
+ A question is whether or not sending mail actually helps us:
+ many users will probably have to come back to us for help; many
+ other users won't care.