95% is pretty extreme.

I have always questioned the balance being struck here, and would welcome
an adjustment of the minimum requirements to run MediaWiki. In many cases,
if we can just require shell access we can automate away the complexity for
the typical use cases.

- Trevor

On Thu, Jan 15, 2015 at 10:49 PM, Max Semenik <maxsem.w...@gmail.com> wrote:

> On Thu, Jan 15, 2015 at 10:38 PM, Bryan Davis <bd...@wikimedia.org> wrote:
>
> >
> > One of the bigger questions I have about the potential shift to
> > requiring services is the fate of shared hosting deployments of
> > MediaWiki. What will happen to the numerous MediaWiki installs on
> > shared hosting providers like 1and1, Dreamhost or GoDaddy when running
> > MediaWiki requires multiple node.js/java/hack/python stand alone
> > processes to function? Is the MediaWiki community making a conscious
> > decision to abandon these customers? If so should we start looking for
> > a suitable replacement that can be recommended and possibly develop
> > tools to easy the migration away from MediaWiki to another monolithic
> > wiki application? If not, how are we going to ensure that pure PHP
> > alternate implementations get equal testing and feature development if
> > they are not actively used on the Foundation's project wikis?
> >
> >
> This is not even about shared hostings: it is pretty obvious that running a
> bunch of heterogenous services is harder than just one PHP app, especially
> if you don't have dedicated ops like we at WMF do. Therefore, the question
> is: what will we gain and what will we lose by making MediaWiki unusable by
> 95% of its current user base?
>
>
> --
> Best regards,
> Max Semenik ([[User:MaxSem]])
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to