-The Git Autoinstaller
-
-TODO NOW:
-
-- Symlinked rerere to get awesomeness. Problems:
- - Permissions
- - Might not make a huge difference; how does it handle empty file
- and removed file cases?
- - Need to manually run git rerere subsequently to reap benefits
- - Majority of resolutions have to happen pre-merge (see below)
- - Consider workflow: run wizard mass-upgrade, and then begin
- resolving working copies one by one. Each time we resolve
- a copy, it should cause other copies to start magically resolving.
- So, ordering should be:
- 1. Perform merge
- 2. If it fails, merge the rr-cache with central rr-cache
- (this operation needs to be atomic) and replace it
- with a symlink. File permissions preferably should
- be made correct, but don't have to be since only root
- will be touching subsequently. If the hash already exists,
- don't do anything (maybe record this for the benefit
- of Mister Kite aka so we don't have to do a full traversal,
- this optimization might be essential)
- 3. When a human is resolving the merges, they are "low
- concurrency", i.e. only one commit recording rerere will
- happen at a time. This means that rr-cache does not
- need to be concurrent safe. Some number of hashes in
- the rr-cache will start having postimages; we'll use
- a full-scan to figure that out. Then cross-reference those
- with the recorded pending resolutions, and figure out which
- checkouts we can run rerere on (this gets permissions kind
- of tricky). We'll try an alternative plan: manually require
- the user run some sort of retry command that does this as
- root; presumably they'd run this every ten installs or
- something. A user can run git rerere to get a resolution
- early.
- This requires some new data-structures:
- - Besides the merge.txt file (which should never ever change),
- we should have an outstanding.txt file which gets modified
- as our scripts do resolutions behind our back. Those modifications
- might a little annoying for a human to keep up with, so we should
- recommend something like watch -n2 "head file" or something
- - We need to keep track of the hashes and the cross-referencing.
- A very small sqlite database might be a good idea here, although
- the type of information we're interested in a somewhat unnatural
- query. Alternatively, we just have a very simple text file.
-- Create 'wizard merge' command
- - Uses application specific hinting to prematurely resolve
- conflicts.
- - Newline resolution gets done prior-merge (presently is done
- post merge).
- - Classes of disappeared files made ok.
- - Make this general utility(?)
-- Need to make script to tell us about all installs that we don't support
- versions of (i.e. this mismatches)
-
-- Wizard needs a correct arch/ setup
-- The wizard command, when not on scripts, should automatically SSH to
- scripts and start executing there?
-- Write the code to make Wordpress figure out its URL from the database
+- Make scripts_plugin email heuristic less stupid, or maybe even ask for an
+ email. This is tracked as Scripts #224 (this issue) and Scripts #193
+ (tracking a contact address).
+- Current parallelization probably does a bad job distributing
+ working tasks over different components of the pipeline. Fix
+ this by adding jitter? Trying to smear things out?
+
+- Test head doesn't do quite the right thing with version numbers
+ (shouldn't git describe, instead should give a version infinitely
+ in the future.)
+- Strategy introspection and disabling.
+- prepare-config (and others) create .wizard dir even
+ when not strictly necessary
+- Bug out immediately if tags are not present in the master tip
+ of the repository
+- pending doesn't seem to get written out properly sometimes (or
+ it's being deleted); this makes it hard to --continue on the
+ event of an upgrade failure. Also, we seem to bounce back to
+ the production copy to check pending even when we run --continue
+ from the working dir.
+- Newline checks are /really really/ expensive on AFS; see if
+ we can minimize them or something. Right now, we're testing
+ a fix where we don't clone with --shared.
+- Replace .split("\n") with .splitlines()
+
+- Need to fix existing repo history? (not adding extra commits;
+ that'll be more difficult)
+
+ git rebase -i -p --root --onto COMMITID
+
+ This won't work if you need to change the very root of the
+ repository. You'll probably end up with conflicts and have
+ to manually resolve everything afterwards.
+
+ But usually you won't need --root --onto unless you really
+ fucked up the pristine branch. If you just need to change
+ the scripts spine,
+
+ git rebase -i -p COMMITID
+
+ should work.
+
+- [SCRIPTS] MediaWiki 1.6.7, 1.9.3 and 1.10.0
+
+- geofft comments:
+ "Connection to scripts.mit.edu closed" is confusing (tracked #393)
+ the URL should be easier to copy and paste, which means we should
+ move it out of dialog
+ We should ... upgrade our autoinstaller
+ Apparently installing WordPress updates or themes never indicates
+ completion, and just says "Downloading..", and you have to guess
+ when it's done
+
+- [SCRIPTS] phpBB
+ - phpBB or phpbb? (right now it's the former)
+ - need an upgrade story; srv needs more versions
+ - need a story about install/ contrib/
+
+- Give users a "certificate" of their merge, which they can
+ use to reuse that merge commit if something unrelated fails.
+
+- Human readable quota output
+- Nice error message on --continue if you forgot to git add your
+ resolved file (look for conflict markers)
+- The merge interface is a kind of major UI disaster; you won't
+ be able to use it unless you know how Git works. Also, the
+ merges can be quite difficult to resolve if upstream has made
+ large formatting changes like reindenting. We may also consider
+ providing a --rebase option, which seems to do better when
+ big problems like this show up.
+
+- Better mass-* support for just one user (this includes letting
+ a user mass upgrade just his own autoinstalls)
+
+- Show progress or something when upgrading
+- Allow 'sticky notes' for future upgraders to notice
+- .wizard/url semantics are subtly wrong: in particular, if we
+ explicitly configure a URL at install, we should be able to
+ detect this URL as baked in from the configuration
+
+- Rerere support doesn't actually work
+- "Version 3.0.0 doesn't exist; did you mean 3.0?"
+- Be a little more intelligent when perform web checks; for example,
+ if we get a forbidden message, that probably means we go the right
+ address but it's blocked off; if we get a 404 message, that probably
+ means wrong address. Account Unknown is something particularly good
+ to check for.
+- Wordpress module can do something intelligent if we get redirected
+ to the installation page.
+- wizardResolve* files seem to get left in tmp en-mass, and we don't
+ know why.
+
+- [SCRIPTS] Wordpress needs to get rid of the siteurl hack, so that it
+ actually has a fully-qualified URL http://foo.scripts.mit.edu/blah.
+ This will also fix Wordpress's cron functionality. We should be
+ careful not to write over users who are on vhosts. We should figure
+ out who is still on twiddle paths. We should make sure the redirect
+ is handled correctly.