TODO NOW:
-- 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
+- XXX: Upgrades don't pull updated tags, breaking git describe --tags!
+ Fix this for the future, and figure out how to make everyone else happy!
+- XXX: Some installs are throwing spurious errors; investigate
+- XXX: Prolly would be nice to have some information about how many installs actually succeeded
+- 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.
+- --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 so they can enter in something different
+- 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
+ - Tidy up common code in callAsUser and drop_priviledges in shell
- Summary script should be more machine friendly, and should not
output summary charts when I increase specificity
- Summary script should do something intelligent when distinguishing
if merge resolutions aren't careful. `php -l` can be a quick stopgap
- Other stuff
- - Make single user mass-migrate work when not logged in as root
+ - 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. 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
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
- A .scripts directory, with the intent of holding Scripts specific files
if they become necessary.
+ - .scripts/dsn, overriding database source name
+
scripts.mit.edu / wizard.git / blobdiff