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

 * The user uploads code with (s)ftp, using a bundle tarball.
 * Can't install anything globally without root rights, so minimal features and performance.

2) Shared hosting with non-root shell

 * The user can use git directly on the server, but can't install anything globally without root.
 * The user can manually download composer to their home directory, and use this instead of git.
 * Can't install anything globally without root rights, so minimal features and performance.

3) Root on a (virtual) server

 * The user can install packages.


 * The user can do any of the above (tarballs, git, composer).

4) 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 (, , etc)
 * Frequently updated dependencies shouldn't require root to track.
 * For example,  is infrequent and thus fine, but I shouldn't need root to update third-party dependencies in the middle of a normal.
 * 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.

Relative distribution of use cases, trends
We are lacking data on the distribution of users, and on any changes in this distribution.

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.