Comparison of distribution options

This is a comparison of different options in distributing MediaWiki, with some pros and cons and notes about extension support for each. There has been some discussion about which distribution strategy we should pick, but I (Legoktm) have come to the conclusion that we should try to support as many as we can do a good job for, and let people use MW in the way that they prefer.

Release tarballs

 * Pros
 * Officially supported by MediaWiki developers and WMF Release Engineering Team
 * Doesn't require knowledge of CLI
 * Composer dependencies are bundled so you don't need to use composer
 * Popular extensions and skins are bundled so those don't need to be downloaded separately
 * Works on any operating system/environment
 * Cons
 * Updating requires manual downloading and extracting over a directory can be tricky (need to back up images/, LocalSettings.php, etc.)
 * Extension support
 * A set of stable, reviewed, and popular extensions and skins are bundled with the tarball
 * Extensions/skins hosted on Gerrit get individual tarballs via ExtensionDistributor

Git

 * Pros
 * Officially supported by MediaWiki developers and WMF Release Engineering Team
 * Used by all developers (at least master is)
 * Easy to cherry-pick bug fixes that don't get backported, or upgrade to changes merged in a release branch but not yet released officially
 * Cons
 * Composer dependencies are not included and must be downloaded separately (via composer or git)
 * Skins are separate and need to be downloaded separately
 * Extension support
 * Any extension managed in a git repo can be used
 * Tarball bundled extensions are now included as git submodules
 * Tarball bundled extensions are now included as git submodules

Debian package

 * Pros
 * Easy as
 * Ensures that all required dependencies are installed properly
 * Present in modern Debian/Ubuntu releases already
 * More likely that users will install optional but recommended PHP extensions/software (e.g. APC, memcache)
 * Package configures logging and sets up a cache directory with correct permissions automatically
 * Cons
 * Only works on a Debian (or derivative) system
 * Requires root access to install
 * Differs from the normal MediaWiki filesystem layout
 * Extension support
 * Currently only supports those extensions bundled with the tarball
 * Individual extensions can be packaged (e.g. Translate)

Docker

 * Pros
 * Used by many developers.
 * Easy setup on Linux, Mac, or Windows (especially with Docker Compose which is included with Docker).
 * Does not require any additional software or configuration.
 * Cons
 * Requires some understanding of how Docker works.
 * May need to extend base image or mount the web root to the host machine to be useful.
 * No default configuration for email, so email will not work out of the box.
 * Not always suited for production, as there is currently little visibility/auditability of the content inside the container, making trust of upstream processes of paramount importance
 * Extension support

MediaWiki-Vagrant

 * Pros
 * Used by many developers
 * Uses puppet for automation, automatically sets up developer environment
 * Supports multiversion, aims to come close to Wikimedia production
 * Easy to deploy to Wikimedia Cloud VPS
 * Cons
 * Intended for developers, not suitable for production
 * Requires a virtual machine or lxc to work
 * Extension support
 * Extensions need to have their "roles" committed to the MediaWiki-Vagrant git repository to work