TODO NOW:
+- We have safe, non-braindead
+ version detection with `git describe --tags`. Switch
+ everything to use it. (I think the only thing left is
+ parallel-find.pl)
+- wizard.util is pretty braindead at this point. Fix up
+ the wildly varying conventions in it.
+- Move migration code into Wizard, since we already deal
+ with installation there anyway.
+
- Better error message if daemon/scripts-security-upd
is not on scripts-security-upd list
-- Add repository flag so that we can specify an
- arbitrary repository to migrate to
- Fix retarded logging mechanism
- The great initial deploy:
- Turn on mediawiki new autoinstaller
- Migrate all mediawiki installs
-- Testing:
- - Need a scriptable autoinstaller, which means we rewrite
- all of the autoinstall machinery. This doesn't need
- to be able to create pre-wizard autoinstalls, since migration
- is easy to test+revert
-
+Doing Wordpress:
- Build automation for generating config files; this automation
will be shared with the migrate script and the installer script
(migrate script needs to be able to pull out values from config
file, so will we; installer script needs to be able to run
the installer to generate config files, so will this)
-
-- Implement proper deploy log parsing; this basically means we
- need to be able to introspect Git Log. Consider using git-python
- for this.
-
- This should all be automated:
- Wordpress needs to have .scripts dir in all -scripts versions
(also make .scripts/.htaccess)
- Summary script should be more machine friendly, and should not
output summary charts when I increase specificity
- Summary script needs to be updated for new format
+
+Some other stuff to do in your copious free time:
- Check how many autoinstalls are missing w bits for
daemon.scripts (this would need pyafs)
-- Make scripts AFS patch advertise its existence so we can check for it
+- Make scripts AFS patch advertise its existence so we can check for it.
+ (This might be otherwise possible using `fs sysname`
+- Implement proper deploy log parsing; this basically means we
+ need to be able to introspect Git Log. Consider using git-python
+ for this.
+- Make 'wizard summary' generate nice pretty graphs of installs by date
+ (more histograms, will need to check actual .scripts-version files.)
PULLING OUT CONFIGURATION FILES IN AN AUTOMATED MANNER
NOTES:
-- A perfectly formed autoinstall with upgrade paths for all of
- the intervening versions is not really feasible to implement.
- As such, we want to migrate everything to -scripts, and then
- generate a -scripts2 with the correct .scripts directory.
- We will then nop update some installs, but this will prevent
- us from having to migrate and update concurrently. Treat
- a scripts2 upgrade from migration the same way you would treat
- a botched scripts upgrade.
- ADDENDUM: You MUST NOT migrate to a -scripts2 version; the
- machinery can't actually handle this.
+- It is not expected or required for update scripts to exist for all
+ intervening versions that were present pre-migration; only for it
+ to work on the most recent migration.
- Currently all repositories are initialized with --shared, which
means they have basically ~no space footprint. However, it
* The new procedure for generating an update is as follows:
(check out the mass-migration instructions for something in this spirit,
- although uglier in some ways)
+ although uglier in some ways; A indicates the step /should/ be automated.)
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
* .scripts/update shell script (with the +x bit set appropriately),
which performs the commands necessary to update a script. This can
- be in any language.
+ be in any language. (XXX: This is going to get removed soon)
* .scripts/.htaccess to prevent this directory from being accessed
from the web.
- * .scripts/database (generated) contains the database the
- user installed the script to, so scripts-remove can clean it
-
- XXX: Could cause problems if a user copies the autoinstall,
- fiddles with the DB credentials, and then scripts-remove's
- the autoinstall. Possible fix is to add the original
- directory as a sanity check. Additionally, we could have
- the application read out of this file.
+ * .scripts/old-version (optional) the old value of .scripts-version,
+ basically used for reverting an install to pre-migrated state.
- * .scripts/old-version (optional) the old value of .scripts-version
+ * .scripts/lock (generated) which locks the autoinstall during an upgrade
- * .scripts/version something like "app-1.2.3-scripts"
-
- * .scripts/install (eventually) interactively installs the
- application from command line. (This might go into wizard.app
- Python module)
-
- * .scripts/lock which locks the autoinstall during an upgrade
-
-* Make 'wizard summary' generate nice pretty graphs of installs by date
- (more histograms, will need to check actual .scripts-version files.)