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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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!
I manage two installations of Mediawiki currently. One of which is on a shared hosting for which I don't have shell access, and the other is on a physical server that I have root access to.
I do plan on switching the shared hosting to a VPS at some point though. Regardless of the route taken, I think that support for the tarball should remain. This is the way that a lot of folks know how to set up web-based software.
And if you guys go the apt-get package route, please make sure that the packages are actually well put together. I've seen some really awful packages for web-based software before, stuff where you were better off just getting the tarball and doing it yourself. I have every bit of faith that the folks in charge of making the packages will do a good job, I just mention it because it has been a problem in the past for me with other software.
Thank you, Derric Atzrott
Just to be clear, this would not affect installation procedure for tarball users. We would pre-load all necessary dependencies and ship them in one package.
The only end users this would affect are people using Git. (Then there’s also the question of whether we want to use third-party libraries in MediaWiki, but that’s another issue entirely.) -- Tyler Romeo 0xC86B42DF
From: Derric Atzrott datzrott@alizeepathology.com Reply: MediaWiki for enterprises mediawiki-enterprise@lists.wikimedia.org Date: June 12, 2014 at 8:15:33 To: MediaWiki for enterprises mediawiki-enterprise@lists.wikimedia.org Subject: Re: [Mediawiki-enterprise] WG: How to make MediaWiki easier to install: use cases
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!
I manage two installations of Mediawiki currently. One of which is on a shared hosting for which I don't have shell access, and the other is on a physical server that I have root access to.
I do plan on switching the shared hosting to a VPS at some point though. Regardless of the route taken, I think that support for the tarball should remain. This is the way that a lot of folks know how to set up web-based software.
And if you guys go the apt-get package route, please make sure that the packages are actually well put together. I've seen some really awful packages for web-based software before, stuff where you were better off just getting the tarball and doing it yourself. I have every bit of faith that the folks in charge of making the packages will do a good job, I just mention it because it has been a problem in the past for me with other software.
Thank you, Derric Atzrott
_______________________________________________ Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
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@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@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:
Shared hosting without shell. The user uploads code with (s)ftp, and can't install anything globally.
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.
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
- 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
mediawiki-enterprise@lists.wikimedia.org