Re: [Wikitech-l] How to make MediaWiki easier to install: use cases

2014-06-11 Thread Daniel Friesen
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

2014-06-11 Thread C. Scott Ananian
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

2014-06-11 Thread Gabriel Wicke
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

2014-06-11 Thread Jeroen De Dauw
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

2014-06-11 Thread Tim Starling
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