I think the vast majority of the people on the Toolserver don't need a lot of that extra "beefy" stuff. To run our tools, all we need is:
* A database providing replication from the Foundation's databases. * A web server capable of running PHP, CGI, and other web scripts. * A linux or solaris machine that we can run bots on. * A platform on which all of this runs reliably.
If any of us needed a Mediawiki installation, we'd have set up our own site for it years ago. Sure, I can see you wanting to make options like that available to developers, particularly those building extensions to MW, but what the Toolserver community - and really, all of the Wikimedia projects - need right now is something that meets those four bullet points. With the Toolserver down as often as it's up lately, and Labs not ready to provide any of that support until December 2013 (not to mention no assistance moving there), either a) the Toolserver needs funding so it can get back to working order, even if it means no further accounts or projects can be created on it, or b) Labs needs to get that stuff running much sooner.
And frankly, I don't see why WMDE should be footing the bill for all the transitioning work when the Foundation isn't providing them any support to do so while setting up a competing system at the same time.
---- User:Hersfold hersfoldwiki@gmail.com
On 9/25/2012 9:30 PM, Erik Moeller wrote:
On Tue, Sep 25, 2012 at 2:27 PM, Platonides platonides@gmail.com wrote:
Hi Platonides.
labs is also a second class citizen.
Moreover, it is explicitely stated not to be for production-like level.
What will happen if a really successful tool reaches to a point where it de-facto needs it ? (eg. a WLM tool, tools to Request to get an Account Created, or Request an Unblock appeal...)
Labs doesn't take options away in those cases -- it's just designed to make it a lot more straightforward to take a tool and integrate it well, if that's the best path to take for a particular tool.
It opens up additional possibilities:
- It makes it easy to set up a MediaWiki instance (we're working on a
standard VM config for this to make it really straightforward) so you can prototype an extension, if that's a direction you want to take for a particular tool. E.g. some of the above sound like they should be ideally done as special pages.
I buy into some of the premise stated here (that a lot of tool developers really don't _want_ to do MediaWiki development), but I also think it's our job to make it as easy as possible to take software down the path that makes the most sense. In contrast, large web apps like MediaWiki are explicitly prohibited from being made publicly available per https://wiki.toolserver.org/view/Rules
- It makes it possible to prototype a standalone service, puppetize
it, and prepare it for production deployment on allocated hardware.
For tools that aren't mission-critical and that are only lightly integrated, I don't view it as an issue for a tool to run at tools.wmflabs.org/some/cool/tool (or wherever it's going to live) indefinitely. (Ryan may want to chip in on that.)
So the tool authors are "on their own", while forced to move out. What is the WMF *offering*?
We're offering free access to very beefy infrastructure for Wikimedia-relevant purposes. We're in this for the long haul and intend to develop Labs into the best environment for testing/staging, bottom-up experimentation and tool development that we can possibly build.
We're not able to provide hands-on support for porting stuff over, but as Ryan suggested, it may be feasible for interested folks to build an environment in Labs that makes transition easier for toolserver users. The Labs team (which includes volunteers) is generally very responsive and helpful, within reason.
Would for instance WMF be willing to lend a few servers to the toolserver until December 2013?
WMDE has to decide what level of transitional support is appropriate and budget for it. As for support, we've kicked around the possibility of them purchasing some additional hardware and us buying it from them later and using it for other purposes, but we'd have to carefully work out whether that's feasible in practice.
Erik