Just thought I'm add my use case, which is very close to 3.
I manage 2 mediawiki installations on separate servers. One is a
shared scenario where I do not have root, but do have full write
access to my installation directory. The second, I have root. In
both cases, I manage both core and extensions using Git. I have not
had the time to look into Composer yet, although I'm not sure why I
would, as I prefer the Git method. My only gripe is I don't track
Extensions as submodules, so I have to upgrade Extensions from the
command line individually using git pull, or git checkout REL1.nn
during version releases.
I really like how I do it now, as it gives me more control, and I'd
hope this method would not go away.
On Wed, Jun 11, 2014 at 6:22 PM, Markus Glaser <glaser(a)hallowelt.biz> wrote:
Hi there,
this is a discussion happening on wikitech-l at the moment. I think this is also of
interest to all the mediawiki users out there ;) Please share your thoughts!
Best,
Markus
-----Ursprüngliche Nachricht-----
Von: wikitech-l-bounces(a)lists.wikimedia.org
[mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Gabriel Wicke
Gesendet: Mittwoch, 11. Juni 2014 20:48
An: Wikimedia developers
Betreff: [Wikitech-l] How to make MediaWiki easier to install: use cases
In the current discussion about git submodules vs. composer there are several different
underlying assumptions about the user's situation. I think it would help the
discussion to clarify which use cases we are dealing with.
Here is an attempt:
1) Shared hosting without shell. The user uploads code with (s)ftp, and can't install
anything globally.
2) Shared hosting with non-root shell and git installed. The user can use git directly on
the server, but can't install anything globally without root. They can manually
download composer to their home directory.
3) Root on a (virtual) server. The user can install packages, and do any of the above.
The git submodules vs. composer discussion seems to focus on case 2). Case
1) could be addressed by providing a 'bundle' tar file with all dependencies that
can be uploaded via (s)ftp. In case 2) composer or git can be used on the server to fetch
dependencies separately.
When using git, it might be worth considering Parsoid's method of making the core
repository a submodule of a 'core-deploy' repository which has all dependencies,
rather than making the dependencies a submodule of core. This avoids issues with git
complaining about dirty submodules in the common case of updating core often.
In case 3) the user has a full packaging system at their disposal, which means that it is
theoretically possible to set up a fully-featured MediaWiki system with a few commands. So
far we don't have any special support for this case (we expect users to follow the
manual tarball setup), which made sense in the past as folks running their own server were
fairly rare.
Many of our users are starting to take advantage of cheap virtual machines though, which
are now widely available at a price point comparable to shared hosting. For this reason I
think that we should put more effort into supporting case 3), for example by providing
good Debian packaging which lets you do "apt-get install mediawiki-full" and get
a MediaWiki install with caching, VisualEditor and so on. There are also other benefits
here beyond the initial install, like automatic security updates with
unattended-upgrades.
So far we don't have a good idea of how common the different use cases are, and how
this distribution is changing. I think that we should try to get this information so that
we can have a more informed debate.
Gabriel
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Mediawiki-enterprise mailing list
Mediawiki-enterprise(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise