Re: [Wikitech-l] How to make MediaWiki easier to install: use cases
On 2014-06-11, 11:47 AM, Gabriel Wicke wrote: 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. ... 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. Shared hosting users using (s)ftp (1) inherently already use our tarball releases exclusively. No-one has suggested requiring extra steps for tarball users, any dependencies we use would be bundled with tarball releases. The only thing being discussed is whether users that have already chosen to use git (and already have git) to clone core (which is technically supposed to be a dev tool even though people like to abuse it for production use) should have to run one extra command (either `composer install` or `git submodule update --init`) before it can be used. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to make MediaWiki easier to install: use cases
As Daniel hinted at, I'd like to add one more use case: (4) prospective developers who want to do a small install for local testing and contribute patches. This turns out to be very similar to use case (2), but it motivates the use of git (rather than a tarball) more strongly. Case (4) also prioritizes low overhead installs, ie can we get the developer setup and productive quickly enough that they don't lose interest. Approaches like using a sqlite3 database help case (4), even though it might not be reasonable to use sqlite for a real wiki (case 2) for performance reasons, regardless of the hosting situation. Gerrit-vs-Phabricator-vs-github and other tooling tradeoffs also matter for use case (4), as we want to minimize the total number of tools and packages the prospective developer needs to install/learn before they can test and submit their first patch. --scott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to make MediaWiki easier to install: use cases
On 06/11/2014 12:29 PM, C. Scott Ananian wrote: As Daniel hinted at, I'd like to add one more use case: (4) prospective developers who want to do a small install for local testing and contribute patches. Scott I have started to summarize the use cases at https://www.mediawiki.org/wiki/Distribution/Use_cases Lets refine that page, so that we can use it as a reference while discussing solutions. Gabriel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to make MediaWiki easier to install: use cases
Also: people with shell but no git. Sent from my mobile device ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to make MediaWiki easier to install: use cases
On 12/06/14 05:29, C. Scott Ananian wrote: As Daniel hinted at, I'd like to add one more use case: (4) prospective developers who want to do a small install for local testing and contribute patches. For development, I like to have everything checked out from some kind of version control system, so that if I need to edit a third-party component, I can easily do that and have my changes tracked, so that a diff or commit can easily be generated. Also, on my laptop, I have a privilege separation boundary between code editing (which is done as the main desktop user) and execution of bleeding-edge code. I think that's a very sensible boundary, since there is all sorts of private data available to the main desktop user, and code from git is often not reviewed. So I'm not going to run composer install hooks on my laptop as a user that can actually install code. So I think for developers, either submodules or explicit git clones are the best solutions. But I don't think anyone is proposing a solution that would prevent explicit git clones. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l