TODO NOW:
-- Make it faster
- - Certain classes of error will continually fail, so they should
- put in a different "seen" file which also skips them, unless
- we have some sort of gentle force
-
- 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
- - Snap-in conflict resolution teaching:
- 1. View the merge conflicts after doing a short run
- 2. Identify common merge conflicts
- 3. Copypaste the conflict markers to the application. Scrub
- user-specific data; this may mean removing the entire
- upper bit which is the user-version.
- 4. Specify which section to keep. /Usually/ this means
- punting the new change, but if the top was specified
- it means we get a little more flexibility. Try to
- minimize wildcarding: those things need to be put into
- subpatterns and then reconstituted into the output.
+ strike out counter of 3)--this requires better error parsing.
+ - IOError should be aggregated, right now contains custom string
+ that makes this not possible. Partition on a colon.
+ - Replace gaierror with a more descriptive name (this is a DNS error)
+ - Stronger skips means that backup failures should also be avoided
+ - Distinguish between types of backup failures
+ - Ignore empty blacklists; they should all have reasons
+ - wizard upgrade should have different exit codes for merge failure
+ and blacklist error
- Distinguish from logging and reporting (so we can easily send mail
to users)
- - Logs aren't actually useful, /because/ most operations are idempotent.
- Thus, scratch logfile and make our report files more useful: error.log
- needs error information; we don't care too much about machinability.
- All report files should be overwritten on the next run, since we like
- using --limit to incrementally increase the number of things we run. Note
- that if we add soft ignores, you /do/ lose information, so there needs
- to be some way to also have the soft ignore report a "cached error"
- - Report the identifier number at the beginning of all of the stdout logs
- - Don't really care about having the name in the logfile name, but
- have a lookup txt file
- 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
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. Also,
+ the Report object should operate at a higher level of abstraction
+ so we don't have to manually increment fails. (in fact, that should
+ probably be called something different). The by-percent errors should
+ also be automated.
+ - Indents in upgrade.py are getting pretty ridiculous; more breaking
+ into functions is probably a good idea
+ - Move resolutions in mediawiki.py to a text file
+ - Investigate QuotaParseErrors
- Other stuff
- Don't use the scripts heuristics unless we're on scripts with the
scripts.mit.edu / wizard.git / blobdiff