TODO NOW:
-- Keep my sanity when upgrading 1000 installs
- - Replace gaierror with a more descriptive name (this is a DNS error)
-
-- 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).
+- ImportError is too broad a catch for make() -- see patch from afarrell
+
+- The calling web code invocations are a mess, with stubs living
+ in the install, deploy modules and the real deal living in util. Furthermore,
+ we use the scripts-specific heuristic to determine where the app
+ lives, and the only reason my test scripts work is because they
+ get manually fed the domain and path by my environment variables.
+
+ Use system similar to database, with option for explicit override,
+ but otherwise attempting to determine from ambient code
+
+- Setting PATH and WIZARD_SRV_PATH from a test script: mention in docs
+- 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.
+
+- wizard install wordpress should ask for password. One problem with this is that
+ Wordpress will still send mail with the wrong username and password, so Wordpress
+ will need to be patched to not do that. Alternatively we can initally set the admin
+ email to a null address and then fix it manually.
+- git diff :1:$file :2:$file to find out what the user did, or is it :3:?
+- php.ini needs to get substituted!
+- --raw parameter for install which means an arbitrary commit can be installed
+- Parse output HTML for class="error" and give those errors back to the user (done),
+ 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)
- 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)
-
- Web application for installing autoinstalls has a hard problem
with credentials (as well as installations that are not conducted
- on an Athena machine.) Possible solutions include asking the user
- to SSH into an athena machine and run a bunch of commands, or writing
- a Java applet (possibly in Clojure or Scala) which gets filesystem
- permissions and then performs the operations.
+ 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
- Genericize callAsUser and drop_priviledges in shell
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? (the parsing overhead
may not be worth it)
- - Investigate QuotaParseErrors
- If a process is C-ced, it can result in a upgrade that has
an updated filesystem but not updated database. Make this more
resilient
- PHP end of file allows omitted semicolon, can result in parse error
- if merge resolutions aren't careful.
+ 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`
0. ssh into not-backward, temporarily give the daemon.scripts-security-upd
bits by blanching it on system:scripts-security-upd, and run parallel-find.pl
- 1. Have the Git repository and working copy for the project on hand.
-
- 2. Checkout the pristine branch
-
- 3. Run wizard `prepare-pristine APP-VERSION`
-
- 4. Checkout the master branch
-
- 5. [FOR EXISTING REPOSITORIES]
- Merge the pristine branch in. Resolve any conflicts that our
- patches have with new changes. Do NOT let Git auto-commit it
- with --no-commit (otherwise, you want to git commit --amend
- to keep our history clean
-
- [FOR NEW REPOSITORIES]
- Check if any patches are needed to make the application work
- on Scripts (ideally, it shouldn't.) Run
- `wizard prepare-new` to setup common filesets for our repositories.
-
- If you are running a PHP script, there is usually a php.ini file
- that we package. You can see previous instances of this patch
- at /mit/scripts/deploy/php.ini/ as well as in the repositories
- of any already migrated scripts. We hope to make these changes
- unnecessary once PHP 5.3 arrives.
+ 1. [ see doc/upgrade.rst ]
- 6. Check if there are any special update procedures, and update
- the wizard.app.APPNAME module accordingly (or create it, if
- need be).
+ [ENTER HERE FROM CREATING A NEW REPO]
- 7. Run 'wizard prepare-config' on a scripts server while in a checkout
- of this newest version. This will prepare a new version of the
- configuration file based on the application's latest installer.
- Manually merge back in any custom changes we may have made.
- Check if any of the regular expressions need tweaking by inspecting
- the configuration files for user-specific gunk, and modify
- wizard.app.APPNAME accordingly.
+ 9. Push all of your changes in a public place, and encourage others
+ to test, using --srv-path and a full path.
- 8. Commit your changes, and tag as v1.2.3-scripts (or scripts2, if
- you are amending an install without an upstream changes)
-
- NOTE: These steps should be run on a scripts server
-
- 9. Test the new update procedure using our test scripts. See integration
- tests for more information on how to do this.
-
- http://scripts.mit.edu/wizard/testing.html#acceptance-tests
-
- GET APPROVAL BEFORE PROCEEDING ANY FURTHER
+[ XXX: doc/deploy.rst ]
+ GET APPROVAL BEFORE PROCEEDING ANY FURTHER;
+ THIS IS PUSHING THE CHANGES TO THE PUBLIC
NOTE: The following commands are to be run on not-backward.mit.edu.
You'll need to add daemon.scripts-security-upd to
12. Run parallel-find.pl to update our inventory
+[ XXX: doc/upgrade.rst ]
* For mass importing into the repository, there are a few extra things:
- * Many applications had patches associated with them. Be sure to
- apply them, so later merges work better.
-
- # the following operation might require -p1
- patch -p0 < ../app-1.2.3/app-1.2.3.patch # [FIDDLY BIT]
-
- * When running updates, if the patch has changed you will have to
+ * When mass producing updates, if the patch has changed you will have to
do a special procedure for your merge:
git checkout pristine
You could also just try your luck with a manual merge using the patch
as your guide.
+[ XXX: doc/layout.rst ]
* The repository for a given application will contain the following files:
- The actual application's files, as from the official tarball