Distribution/Use cases

This page summarizes different use cases for our distribution and packaging efforts. It does not consider large third-party organizations (including specialized MediaWiki hosting services) with the resources to do their own packaging and deployments.

1) Shared hosting without shell

Uploads code with (s)ftp, using a bundle tarball.
Can't install anything globally without root rights, may lack some "specialised" package.
Can't run any crontab, maintenance script or other commands when required for setup.

2) Shared hosting with non-root shell

Can use (s)ftp uploads as in 1).
Can't install anything globally without root rights, may lack some "specialised" package.
Can run non-privileged commands directly or with cron.
If git is installed, the user can use git directly on the server.
Can manually download composer to their home directory, and use this instead of git.

3) Root on a (virtual) server

Can install packages.
The user can do any of the above (tarballs, git, composer).

4) Wiki farm

From a handful to thousands wikis.

Sysadmins have root access
Shared codebase across several wikis
Sysadmins and possibly normal shell users should have an easy way to create new wikis using the shared codebase
Extensions might differ per wiki
Need bulk upgrade support for all wikis per system

5) Developer on a typical single-user machine (Mac/Windows/Linux)

Runs a (typically small) test wiki off git
Contributes code back to MediaWiki
Goal is to make the process of contributing the first patch as painless as possible
- Painless and *temporary* -- for infrequent contributors it should be easy to uninstall packages and undo whatever configuration changes are made after the patch is submitted/merged.
- Applies to mediawiki, its dependencies, and to the bug tracking, version control, patch submission, and code review environment.
Typically has root in development environment, but doesn't like to use it.
- When possible, root should be used only to install distro packages (via apt, yum, homebrew), not to make arbitrary changes.
- When possible, tools should be able to install and run from a local user directory with normal user permissions ($HOME/bin, $HOME/public_html, server ports >= 1024, etc)
- Frequently updated dependencies shouldn't require root to track.
  - For example, apt get update php5 is infrequent and thus fine, but I shouldn't need root to update third-party dependencies in the middle of a normal git bisect.
Protected from typical newbie mistakes
- For example, a new developer shouldn't have to install and remember to run a linting tool. It should either be transparently integrated in the code review environment or else the lint should be run on WMF hardware as part of integration tests.

6) Vendor branch

This approach is found in corporate environments that develop proprietary wiki extensions. Official MediaWiki code is not deployed directly, but merged into the company version control system using a vendor branch model.

This use case is most similar to the ordinary tarball release, as everything else happens behind the scenes at the company. However, it's important that Wikimedia not break this use case.

The user downloads latest release's bundle tarball, unpacks it, and adds the contents to the company version control system (subversion, git, or whatever).
A diff is calculated between the company codebase and the official release using a vendor branch approach.
This diff is merged into the company codebase, bringing it up to date with the official release.
Very likely, this merged release is deployed to development, test, and production environments, some of which may be server farms.

Relative distribution of use cases, trends

We are lacking historical data on the distribution of users, and on any changes in this distribution. However, for public wikis there is a fairly representative queryable dataset: wikiapiary:WikiApiary:Hosting providers is one example report, more can be added with some SMW charts.

There is speculation and anecdotal evidence that use case 3) is becoming more popular as virtual servers are now available at a price point similar to shared hosting.