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
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
case 1) here on multiple wikis. Please dont follow the example of Extension:Maps (which is nearly impossible to install without composer) and continue to provide some easy method to install mediawiki for people like me.
Am 12.06.2014 00:22, schrieb Markus Glaser:
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
We're not discussing composer in the way extensions use it.
We're only discussing the possibility that a *git* clone of core should require either `composer install` or `git submodules update --init` to run as new 3rd party libraries we use wouldn't be carelessly dumped into the mediawiki/core repo anymore. Tarballs will continue to be bundled with all 3rd party libraries we use and will still work out of the box.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2014-06-13, 3:02 AM, Stip wrote:
case 1) here on multiple wikis. Please dont follow the example of Extension:Maps (which is nearly impossible to install without composer) and continue to provide some easy method to install mediawiki for people like me.
Am 12.06.2014 00:22, schrieb Markus Glaser:
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
On Fri, Jun 13, 2014 at 7:37 AM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
We're not discussing composer in the way extensions use it.
We're only discussing the possibility that a *git* clone of core should require either `composer install` or `git submodules update --init` to run as new 3rd party libraries we use wouldn't be carelessly dumped into the mediawiki/core repo anymore. Tarballs will continue to be bundled with all 3rd party libraries we use and will still work out of the box.
So if this happens would that mean the next time I upgrade my installations with a "git pull" I'd need to either first install composer or do a "git submodules update --init"?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2014-06-13, 3:02 AM, Stip wrote:
case 1) here on multiple wikis. Please dont follow the example of Extension:Maps (which is nearly impossible to install without composer) and continue to provide some easy method to install mediawiki for people like me.
Am 12.06.2014 00:22, schrieb Markus Glaser:
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
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org