TODO NOW:
-- 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!
-- 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.
+- Write the code to make Wordpress figure out its URL from the database
- 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)
+- 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.
- Web application for installing autoinstalls has a hard problem
with credentials (as well as installations that are not conducted
operations.
- Pay back code debt
- - Tidy up common code in callAsUser and drop_priviledges in shell
+ - Tidy up common code in callAsUser and drop_priviledges in shell;
+ namely cooking up the sudo and environment variable lines
- 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
- 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
also be automated.
- Move resolutions in mediawiki.py to a text file? (the parsing overhead
may not be worth it)
- - 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. `php -l` can be a quick stopgap
- It should be able to handle installs like Django where there's a component
that gets installed in web_scripts and another directory that gets installed
in Scripts.
- - ACLs is a starting point for sending mail to users, but it has
- several failure modes:
- - Old maintainers who don't care who are still on the ACL
- - Private AFS groups that aren't mailing lists and that we
- can't get to
- A question is whether or not sending mail actually helps us:
- many users will probably have to come back to us for help; many
- other users won't care.
+
+- ACLs is a starting point for sending mail to users, but it has
+ several failure modes:
+ - Old maintainers who don't care who are still on the ACL
+ - Private AFS groups that aren't mailing lists and that we
+ can't get to
+ A question is whether or not sending mail actually helps us:
+ many users will probably have to come back to us for help; many
+ other users won't care.
PULLING OUT CONFIGURATION FILES IN AN AUTOMATED MANNER
And then apply the patch. If the patch is complicated, you may get
warnings about hunks already being applied; you can ignore those warnings
(don't assume ``-R``!)
+
+Going retro
+-----------
+
+Under certain circumstances, you may need to splice in older versions
+of the application into your history. Do not rebase: you should never
+rebase published history. Instead, use the following procedure:
+
+Identify the version that, with regards to version numbering,
+directly precedes the version you'd like to add. For example, if
+you have the following commit tree:
+
+.. digraph:: original_dag
+
+ node [shape=square]
+ subgraph cluster_master {
+ bs -> as
+ as [label="1.0-scripts"]
+ bs [label="2.0-scripts"]
+ label = "master"
+ color = white
+ }
+ subgraph cluster_pristine {
+ b -> a
+ a [label="1.0"]
+ b [label="2.0"]
+ label = "pristine"
+ color = white
+ }
+ bs -> b
+ as -> a
+
+And you are adding the 1.1 version, 1.0 and 1.0-scripts are the
+tags immediately preceding this version. Create temporary
+branches (we'll name them ``tmaster`` and ``tpristine``) pointing
+to these tags::
+
+ git checkout -b tmaster
+ git reset --hard 1.0-scripts
+ git checkout -b tpristine
+ git reset --hard 1.0
+
+Find the committer time associated with the commit using ``git show``
+and note it somewhere (we will refer to it in the environment variable
+``$TIME``.)
+
+Next, begin performing ordinary procedure for preparing the
+pristine copy. There are two caveats: you will need to use ``--force``
+to make ``wizard prepare-pristine`` not complain about not being on
+the ``pristine`` branch, and you will need to falsify the author
+and committer time on the commits to be the times we noted down
+previously::
+
+ # on the tpristine branch
+ wizard prepare-pristine $APP-$VERSION --force
+ env GIT_AUTHOR_DATE="$DATE" GIT_COMMITTER_DATE="$DATE" git commit -asm "$APPLICATION $VERSION"
+ git tag $APP-$VERSION
+
+.. note::
+
+ The date falsification is necessary to make Git prefer the
+ later version tag when a commit has this (newer) commit and
+ the most up-to-date version as merge parents. By default
+ Git prefers the temporally closest commit.
+
+Next, merge the changes to the scriptsified ``tmaster`` (not ``master``!) copy,
+and falsify the dates as well::
+
+ git checkout tmaster
+ git merge tpristine --no-commit
+ # resolve conflicts
+ env GIT_AUTHOR_DATE="$DATE" GIT_COMMITTER_DATE="$DATE" git commit -asm "$APPLICATION $VERSION-scripts"
+ git tag $APP-$VERSION-scripts
+
+Note that we are creating a tag, because otherwise there is not an easy way
+to refer to this non-HEAD tag. On a scripts server with Wizard pointed at the
+latest version, run::
+
+ cd tests
+ env WIZARD_NO_COMMIT=1 ./test-install-$APP.sh $VERSION
+ cd testdir_install_$APP_$VERSION
+ wizard prepare-config
+
+Note that ``$VERSION`` is specified explicitly. If there are changes,
+manually restore any custom changes we may have made, then amend your commit and
+push back::
+
+ git commit --amend -a
+ git tag -d $APP-$VERSION-scripts
+ git tag $APP-$VERSION-scripts
+ git push --force
+ git push --force --tags
+
+And on your now invalid version, grab the new version::
+
+ git fetch --tags --force $REMOTE
+
+Note that there is no need to reset the master branch, which hasn't changed.
scripts.mit.edu / wizard.git / commitdiff
