-- Fix MediaWiki 1.11.0 Setup.php (we incorrectly applied the scripts
- patch when it was actually not in this version) --- we need to figure
- out the sequencer NOW.
-- Genericize callAsUser and drop_priviledges in shell
-- Remove "already migrated" cruft that will accumulate if we do small
- --limit and then increase.
-- Make sure to generate reports about what errored and what had warnings.
- Same goes for our output
-- Change from using hashes to using numbers corresponding to when we
- processed them (padded to 7 width) and make sure we sort listdir
- the versions directory.
-- Allow to migrate just one user (user filtering of installs)
-- Make sure MediaWiki upgrade script gives correct exit code if it fails.
-- Custom merge algo: absolute php.ini symlinks to relative symlinks
-- Custom merge algo: re-constitute AdminSettings.php if missing. It looks
- like this is the case for most 1.5.8 installs (check what the merges
- do in both directions). All 1.11.0 installs except four have
- the other (check diff -u with all in /root)
-- Further reduce logging by making sh.call() debug?
-- Fix dirty code for handling remigrating migrated code. This is
- dirty because we overload the meaning behind version "1.2.3"
- for both the pristine copy, and for an unmigrated install.
-
-- Make parallel-find.pl use `sudo -u username git describe --tags`
- to determine version. Make parallel-find.pl have this have greater
- precedence.
-- Make the installer use 'wizard install' /or/ do a migration
- after doing a normal install (the latter makes it easier
- for mass-rollbacks).
-- Have the upgrader/migrater do locking (.scripts/lock, probably)
-
-- Better error message if daemon/scripts-security-upd
- is not on scripts-security-upd list
-
-- The great initial deploy:
- - Turn on mediawiki new autoinstaller
- - Migrate all mediawiki installs
- - Build research scripts, determine if a re-migration is necessary
-
-- Make upgrade and install take version as a parameter
-
-- Redo Wordpress conversion, with an eye for automating everything
- possible (such as downloading the tarball and unpacking)
-
-- Summary script should be more machine friendly, and should not
- output summary charts when I increase specificity
-
-Some other stuff to do in your copious free time:
-- Summary script should do something intelligent when distinguishing
- between old-style and new-style installs
-- Check how many autoinstalls are missing w bits for
- daemon.scripts (this would need pyafs)
-- Make scripts AFS patch advertise its existence so we can check for it.
- (This might be otherwise possible using `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.
-
-PULLING OUT CONFIGURATION FILES IN AN AUTOMATED MANNER
-
-advancedpoll: Template file to fill out
-django: Noodles of template files
-gallery2: Multistage install process
-joomla: Template file
-mediawiki: One-step install process
-phpbb: Multistage install process
-phpical: Template file
-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.
+- If no newlines at all, DON'T CARE (don't rewrite the file again!)
+- Plugin-ify!
+
+- Add support for mypristine workflow
+- Wordpress needs to get rid of the siteurl hack, so that it actually
+ has a fully-qualified URL http://foo.scripts.mit.edu/blah. This will
+ also fix Wordpress's cron functionality. We should be careful not
+ to write over users who are on vhosts. We should figure out who is
+ still on twiddle paths. We should make sure the redirect is handled
+ correctly.
+
+- Remerges aren't reflected in the parent files, so `git diff` output is
+ spurious. Not sure how to fix this w/o tree hackery.
+- Sometimes users remove files. Well, if those files change, they automatically
+ get marked as conflicted. Maybe we should say for certain files "if they're
+ gone, they're gone forever"? What is the proper resolution?
+
+- Parse output HTML for class="error" and give those errors back to the user (done),
+ then boot them back into configure so they can enter in something different
+
+- If you try to do an install on scripts w/o sql, it will sign you up but fail to write
+ the sql.cnf file. This sucks.
+
+- Web application for installing autoinstalls has a hard problem
+ with credentials (as well as installations that are not conducted
+ on an Athena machine.) We have some crazy ideas involving a signed
+ Java applet that uses jsch to SSH into athena.dialup and perform
+ operations.
+
+- Pay back code debt
+ - Tidy up common code in callAsUser and drop_priviledges in shell;
+ namely cooking up the sudo and environment variable lines
+ - Summary script should be more machine friendly, and should not
+ output summary charts when I increase specificity
+
+- Other stuff
+ - Figure out why Sphinx sometimes fails to crossref :func: but wil
+ crossref :meth:, even though the dest is very clearly a function.
+ Example: :func:`wizard.app.php.re_var`
+ - The TODO extension for Sphinx doesn't properly force a full-rebuild
+ - Make single user mass-migrate work when not logged in as root. The
+ primary difficulty is making the parallel-find information easily
+ accessible to individual users: perhaps we can do a single-user
+ parallel-find on the fly.
+ - 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.
+
+[ XXX: metadata.rst ]