On Tue, Apr 30, 2013 at 8:02 PM, MZMcBride <z(a)mzmcbride.com> wrote: Yes, there will always be some contingent that's upset at the seemingly > underhanded way in which Labs was brought into the world (simply announced > one day, with the implicit acceptance that the German Toolserver would be > put down in time or left to rot), but I think there are far more people > who don't support or are ambivalent toward Labs when these people could > and should be proponents for it. Labs just needs a bit better public > relations, in my opinion. Just because the events coincided didn't mean they were connected. You've simply assumed this (in bad faith). WMF wanted a virtual environment for testing and development during the usability initiative. Tesla was the first iteration of that. I was hired as full staff shortly afterward as an operation engineer to build a virtual cluster. I very heavily disliked creating virtual machines for people, then configuring them, setting up user accounts, ssh keys, rights, etc.. I wanted people to do that themselves. That's when I started looking at some clustering services that allowed self-service provisioning. The multi-tenancy of OpenStack is what started forming my ideas for Labs. When I started working on it, I decided that this would be something really useful to have open to the entire community. The multi-tenancy meant we could have communities run different projects; it felt like how we run the content portion of our community. I especially wanted this because I didn't like that we were unable to give shell/root to community members and wanted a way for us to eventually allow that again. Toolserver wasn't even a consideration of mine. Using Labs to replace TS wasn't really an idea till a short time before the beta launch at the New Orleans hackathon. The work that's been concentrated on so far was my original roadmap for Labs and we're just now starting to hit the TS feature sets. Since the really poor initial reaction to the deprecation of TS, I've avoided doing any marketing whatsoever, because it tended to cause flamewars. Instead I worked on stabilizing Labs and starting on the necessary features to enable tool labs. Thankfully Coren has been able to work on this fully, which has greatly accelerated the schedule. We now have Silke and Sumana working with everyone, so I feel the marketing aspect will improve. We have "move your tool/bot" workshops running the entirety of the Amsterdam Hackathon and the Wikimania Hackathon, the latter being a mass migration hackathon (hopefully). - Ryan

(anonymous) wrote: The problem with this decision is the effort spent and the insincerity. If database replication for Labs would have meant moving some dbxxx servers to labsdbxxx, adding the views existing on Toolserver and tightening some firewall rules, it could have been set up in a month, and any moaning about having to use federated tables would have been si- lenced by the minutes it would take to add another server to the cluster to increase performance compared to the years it takes at Toolserver. Or there could have been some new concept like Galera men- tioned by Nosy that eases maintenance because it is not some sparsely documented Solaris thingy in River style. But now the plan is to have two clusters (PreLabsDBDBS and LabsDB), use triggers to remove data and then (addition- ally!) views, end up with less functionality than the Toolserver while gaining nothing, and all that takes half a year to set up in a cloak-and-dagger way while publicly the need for cross-database JOINs is acknowledged. Tim