X-Git-Url: https://scripts.mit.edu/gitweb/wizard.git/blobdiff_plain/05d452073bdb008549a4a69ef47660a7e37115b7..3f18b7fff1c5d5cd3d91897a85a425704ba4295e:/TODO diff --git a/TODO b/TODO index b85c57f..4288d07 100644 --- a/TODO +++ b/TODO @@ -2,10 +2,37 @@ The Git Autoinstaller TODO NOW: +- --retry option for install, so it won't complain about a directory already + being there. +- 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. + + We will record the URL used for the initial installation, and save it in + .scripts/url. If autodetection in either direction is + available, we verify this value against the actual file path the installation + lives in (for the scripts case, we can do a file-level comparison because we + know the web root of any given file). If they mismatch, we error out + and have someone manually resolve the problem. If autodetection is not + available, we use the saved .scripts/url for operations. + +- wizard install wordpress should ask for password +- 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 + do a test script with x.y.z when we REALLY mean x.y.z-scripts. XXX!!! - Do early validation of inputs for configuration - 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) @@ -42,6 +69,11 @@ TODO NOW: 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` @@ -112,56 +144,16 @@ OVERALL PLAN: 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. + 1. [ see doc/upgrade.rst ] - 2. Checkout the pristine branch + [ENTER HERE FROM CREATING A NEW REPO] - 3. Run wizard `prepare-pristine APP-VERSION` + 9. Push all of your changes in a public place, and encourage others + to test, using --srv-path and a full path. - X. Commit, with name "Appname x.y.z" - - 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. - - 6. Check if there are any special update procedures, and update - the wizard.app.APPNAME module accordingly (or create it, if - need be). - - 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. - - 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 @@ -180,15 +172,10 @@ OVERALL PLAN: 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 @@ -208,6 +195,7 @@ OVERALL PLAN: 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