TODO NOW:
+- Test code should auto-nuke the database using `wizard remove` before doing a new install
+- git diff :1:$file :2:$file to find out what the user did, or is it :3:?
+- Document how to fix a broken upgrade
+- php.ini needs to get substituted!
- Make wizard install accept appname-head (so that you can do a test with
head, and do things without tags). Also make it accept commit hashes.
In fact, let it accept any committish. Figure out what to do if we
- Let 'wizard configure' be interactive
- Parse output HTML for class="error" and give those errors back to the user,
then boot them back into configure
+- Get rid of our custom sizing code and use dialog's built-in sizing (i.e. width=0, height=0).
+ Maybe our sizing code is superior, maybe not.
- Replace gaierror with a more descriptive name (this is a DNS error)
if merge resolutions aren't careful. `php -l` can be a quick stopgap
- 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
+ - Code annotation!
- Make single user mass-migrate work when not logged in as root
- Don't use the scripts heuristics unless we're on scripts with the
AFS patch. Check with `fs sysname`
X. Commit, with name "Appname x.y.z"
+ X. Tag as appname-x.y.z
+
4. Checkout the master branch
5. Merge the pristine branch in. Resolve any conflicts that our
inheriting from wizard.app.Application (check existing modules for
the boilerplate code).
- 2. Implement download()
+ 2. Implement download(). "wizard prepare-pristine" will use this in order
+ to download the next version of an application.
3. Create a git repository with `git init`
- 4. Use `wizard prepare-pristine APP-VERSION`
+ 4. Use `wizard prepare-pristine APP-VERSION` to download the tarball and
+ extract it into the directory. If download() doesn't work and you don't
+ want to special case it (for example, you need a /really old version/
+ for record-keeping purposes), replace APP-VERSION with PATH, where PATH
+ is the tarball to extract.
5. `git commit -asm "APP VERSION"`
10. Implement install(). Test using `wizard install APP`; you won't
be able to do a version-specific install with `wizard install APP-VERSION`
until you generate a tag (which will become out of date once you
- amend the commit.)
+ amend the commit.) Now might be a good time to create a
+ tests/test-install-APP.sh file (use the other tests as reference) so
+ you don't have to constantly enter the parameters when you're doing
+ an install.
11. Push your changes to a directory accessible in the production environment.
In the case of scripts, this is equivalent to your AFS homedir, and
perform a configuration in the production environment to extract
out the canonical configuration files.
- 12. On the production server, call your wizard to perform an installation.
- Inspect the generated configuration files, and implement:
+ 12. On the production server, call your wizard to perform an installation;
+ be sure to use the option --no-commit in order to make propagating changes
+ back easier. Inspect the generated configuration files (you can use `git
+ status` to find unversioned files that the installer created), and
+ implement:
- extractors
- substitutions
These are dictionaries of functions that perform extraction
script was buggy; try again.
14. The current changes in the working copy should be merged in. Add any new
- files, and then `git commit --amend`.
+ files, and then `git commit --amend`. `git push --force` to stick these
+ changes back in the "public" repository.
15. In your local copy, you can pull the changes by doing `git reset --hard HEAD~`
and then a `git pull` from the relevant source. Otherwise, Git will complain
scripts.mit.edu / wizard.git / blobdiff