Set admin e-mail address properly on MediaWiki >= 1.18.0
[wizard.git] / VISION
1 Wizard originally grew out of a simple itch for MIT Scripts
2 autoinstallers: we had grown a suite of tools for letting
3 users easily install web applications, but we had been completely
4 negligent in keeping these applications up to date.  There was
5 automation to be built, and Wizard originally was meant to let
6 us perform updates on these autoinstallers.
7
8 As subsystems started being built, I started to notice that
9 Wizard was starting to develop into something more generally
10 applicable than just "mass upgrades for Scripts autoinstalls"--
11 perhaps the first instance of this was when I noticed that there
12 wasn't really any good reason that 'wizard upgrade' couldn't
13 be run by the user, and not just us in the process of a mass
14 upgrade.
15
16 Wizard wants to solve three problems:
17
18     1. It is a better package manager for web applications.
19        This means making it easy to install and upgrade web applications,
20        all of which may be coexisting on the same machine (something
21        traditional package managers don't manage well.)  It also means
22        bringing a /consistent/ interface for maintaining all applications
23        it supports.
24
25     2. It solves the problem of maintaining your own patchsets on top
26        of an application, and not just getting those blindly written
27        over and getting intelligent merging and conflict markers of
28        these patches.
29
30     3. It enables to do this on a large scale, on the order
31        of thousands of installs.  To do this, we also standardize
32        an interface for backing up filesystem and non-filesystem data
33        as well.
34