If you're asking "is it safe to move tools to Labs", my experience so far say "yes". I can't speak for all unique toolserver features, though. Cheers, Magnus On Sat, Aug 10, 2013 at 10:36 AM, Dr. Trigon <dr.trigon(a)surfeu.ch> wrote: -- undefined

Hi, DrTrigon, hi all! Here are the essentials: * Please migrate your tools to Tool Labs until June 30th 2014. (Roadmap: http://www.mediawiki.org/wiki/Tool_Labs/Roadmap_en) * Yes, there are replicas of the databases and many other features. It is made similar to the login servers on TS. * Subscribe to labs-l https://lists.wikimedia.org/mailman/listinfo/labs-land/or join #wikimedia-labs on freenode. There are lots of people who will help you. * Most tools will just run when you copy them to Tool Labs. Just in case: Need help adapting a tool? Ask me and I'll do what I can to get you help, e.g. from my colleague Johannes Kroll. * If you figure out things that aren't documented, please help others by writing it down, on-wiki (link below) or on labs-l. * Read this list for updates. * Some links: ** Tool Labs start page: https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools ** Tool Labs documentation: https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help (Documentation is ongoing, your help is appreciated!) Any more specific questions? Please ask! :) Greetings from Wikimania, Silke 2013/8/11 Alex Brollo <alex.brollo(a)gmail.com> -- Silke Meyer Internes IT-Management und Projektmanagement Toolserver Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 260 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

On Tue, Aug 13, 2013 at 6:51 AM, Maarten Dammers <maarten(a)mdammers.nl>wrote;wrote: I don't think that's a fair representation. Despite some teething problems, Labs has been at least (probably more) reliable than the toolserver in the time I've been there. I have ported 25 tools to Labs now, including some heavy-duty ones, and they all seem to work fine. Yes, there is the occasional bug (imagelinks table on cawiki is not working at the moment; roots are en route from Wikimania;-) but I don't see the traditional toolserver slowness, and Labs doesn't occasionally vanish behind 504 errors for hours at a time either.

Silke Meyer (2013-08-11 08:36): Two questions: 1. What will happen after June 2014? Specifically - what will happen to any tools and repositories (SVN) that will still be on TS after that date? Will TS cease to exist, will it be inaccessible, just databases will be inaccessible or stale or what? 2. When will users from TS be able to fully use GIT? I'm asking because this page <https://wikitech.wikimedia.org/wiki/Help:Git> gives some information on migration process, but also mentions that Push access is not available. Which is kind of strange because, as I understand, I would be creating my own repository. I'm actually hoping this page just wasn't updated ;-). Regards, Nux.

On 11/08/13 08:36, Silke Meyer wrote: Provide a toolserver.wiki table please.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes that was also my experience - I started using Labs under the bots project and it was not that reliable than TS, e.g. no backups of the file system and stuff like that - hope this has changed with the tools project now. get > you help, e.g. from my colleague Johannes Kroll. E.g. what about E-Mail? Do I have the possibility to forward mail addresses like e.g. drtrigonbot(a)tools.wmflabs.org into a file? Greetings DrTrigon

Hello, Am 19.08.2013 23:49, schrieb Dr. Trigon: yes, it is still the plan. The hiring of a second admin is independent of everything. Sincerely, DaB.

On Mon, Aug 19, 2013 at 11:31 PM, Ryan Lane &lt;rlane(a)wikimedia.org&gt; wrote: Yes, this is my fault- apologies for the delay. I will address it when I get back from the CC Summit I'm attending right now. Luis -- Luis Villa Deputy General Counsel Wikimedia Foundation 415.839.6885 ext. 6810 NOTICE: *This message may be confidential or legally privileged. If you have received it by accident, please delete it and let us know about the mistake. As an attorney for the Wikimedia Foundation, for legal/ethical reasons I cannot give legal advice to, or serve as a lawyer for, community members, volunteers, or staff members in their personal capacity.*

On Thu, Aug 29, 2013 at 3:11 AM, Dr. Trigon &lt;dr.trigon(a)surfeu.ch&gt; wrote: If it isn't free, then it isn't open source. All we require is a valid OSI license. If it doesn't fit that license we either need to grant an exception (which isn't likely), or the tool author needs to use a different library. The projects depend on the tools. If a tool is abandoned then we need to be able to take over the tool, which includes its source. If the tool is using something proprietary then it makes taking it over difficult or impossible. Here's my stance: if a tool is using something proprietary, we can't count on that tool and it doesn't belong on Labs. The tool author either needs to switch to an open source library or move the tool to their own infrastructure. - Ryan

On Thu, Aug 29, 2013 at 8:12 AM, DaB. &lt;ts(a)dabpunkt.eu&gt; wrote: Please read: http://opensource.org/osd-annotated Or people are free to move them to infrastructure that isn't funded by the donations to a movement that has Open Content as one of the five pillars < http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_is_free_content>gt;. The tools and bots that keep this content alive and free are in my opinion an extension of that pillar. I'm more than happy to recommend a number of cloud services and am more than willing to give advice on how to configure and run tools and bots from those services. It's even possible to reuse the work we're doing in the tools project, or in the Wikimedia infrastructure via our puppet repository since our infrastructure is Open Source. - Ryan

On Fri, Aug 30, 2013 at 2:36 AM, DaB. &lt;ts(a)dabpunkt.eu&gt; wrote: The term was coined by the folks from the OSI. See their opinion on open source vs free software: <http://opensource.org/faq#free-software> Just because the term is often misused to also cover software that is not free and has the source available doesn't mean it's a correct use of the term. Tools and bots are depended on by the movement to properly run. They're an extension of the infrastructure. The projects should be forkable and that includes the tools and bots that keep it running. You're arguing to keep parts of the infrastructure closed source. To what end? How many tools are currently using closed source? How hard would it be to modify them to use open source alternatives? What happens to these tools if they are abandoned? How does this actively benefit the movement? Assuming you found a non-profit, host your infrastructure somewhere that doesn't cause legal issues and every person that has access to the data stream signs an NDA it's likely doable. Of course, what you're proposing is to fork the community and to explicitly split the tool/bot authors from the software developers and operations engineers. You're also doubling resources and used funds. Aren't we supposed to be a collaborative community? Why can't we work together on this? I don't understand your antagonism. The new environment that's being provided is an infrastructure for building infrastructures and tools is a fork of TS that runs inside of it. It scales horizontally, is well funded, its underlying infrastructure and the database replication is maintained by the foundation's operations team at a production support level, it's completely open source and forkable and it allows and encourages volunteer roots (which could include yourself). We're not killing TS, we're simply providing a new home for it. You're fighting against something that is providing everything you've been asking for and more. - Ryan

Hi, Can you elaborate? On Thu, Aug 29, 2013 at 8:14 PM, Merlissimo &lt;merl(a)toolserver.org&gt; wrote: What makes these closed? Whose copyrights are the limiting factor here? (links to the pages for those things if they exist would be great. e.g. libraries) What's OTI? Please don't use free to mean "no cost" on this thread. In fact, it would be good to avoid "free" entirely. For "free software" use libre and for "free as in beer, no cost to use" use gratis. -Jeremy

On Thu, Aug 29, 2013 at 1:14 PM, Merlissimo &lt;merl(a)toolserver.org&gt; wrote: That's great, I'm happy to hear that WMDE is helping with this. Boring it may be, useless it is not. Wikimedia is founded on free software / open source principles, for many good reasons, some of which have already been given in this thread. If the policy is motivating the elimination of a proprietary dependency for tools that are important and valuable to our projects, that means the policy is having its intended effect. In other words, your example underscores precisely why treating this kind of policy as non-negotiable is important, and why we will continue to do so. Non-free licenses of various kinds ("use it for free", "use it for non-profit purposes", "you can inspect the code") may be tempting, but tend to cause problems in the long run -- due to changes of terms by the original developer, lack of compatibility with other licenses, lack of adaptability of the code, problems distributing the code in open source contexts, and so on and so forth. On the upside, when open source projects eliminate proprietary dependencies, this is often the source of innovation and positive change that benefits more than just the project in question. The story of the Linux dependency on BitKeeper ( see https://en.wikipedia.org/wiki/BitKeeper ) is a good example of that. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

Am 30.08.2013 00:08, schrieb Erik Moeller: good luck with using GPL-code in a BSD-project, or CC-text in GFDL-document. Mixing licenses are problematic most times, no matter if open-source-ones or proprietary ones. And Wikimedia was not founded ON free-software, but WITH free-software – because it was the cheapest solution. Or does somebody think we hadn’t use MySQL if it would have been only gratis and not open-source? And bitkeeper is very good example: Was the Linux-kernel unfreeer than today? No it was not. It doesn’t matter what tools you use to create free content. „Entscheidend ist, was hinten raus kommt.“. (A funny fact is that Merlissimo and I use Thunderbird on Linux (free software on a free OS), while Ryan and Erik use Google mail (a gratis and non-open-source web-service)…). Good night, DaB.

On Fri, Aug 30, 2013 at 1:57 AM, Ryan Lane &lt;rlane(a)wikimedia.org&gt; wrote: I don't think licenses usually work that way. If I share some code under an open source license, I can't later decide to revoke it. Similarly, if I share some application or library under a freeware license (gratis, but not open source), I think I can't later decide to just revoke it (unless the original license terms clearly stated that I can do that, or unless it was a time-limited license to begin with). I can decide to put later versions of the software under different terms but that's all I can do. Petr Onderka [[en:User:Svick]]

Hi! I think that everybody understands that with the migration we ask you volunteers a lot, especially if your tools can't just move as they are: You have been doing this extra work as a hobby for *years* which I have a lot of respect and admiration for. Still, I am reluctant to repeat discussions we had before because the situation hasn't changed: OSI-approved licenses only. I take the wording "exceptions are possible but unlikely" as "no exceptions" until I hear of one, ok? ;) For non-libre projects I would like to come back to what Ryan wrote: Ryan, Luis, could you write a bit more about whether it would be ok (technically and legally) to run database queries in Tool Labs and send them to an external server where a proprietary tool runs? Is that a no go? An exception? Is it totally fine? Concerning the support offer: As we (as in WMDE) announced to accept support requests for migration until September 30th 2013, I take it there is not that much need of it: So far, my colleague Johannes is in touch with two projects only (Merlissimo among them). If I am wrong, maintainers, please contact me in the weeks to come! Cheers, Silke -- Silke Meyer Internes IT-Management und Projektmanagement Toolserver Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 260 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

Hello Ryan, Am 29.08.2013 21:09, schrieb Ryan Lane: just a notice here: The Toolserver IS everything I asked for. It’s only problem is that it is underfunded. Otherwise it is great. It has a living community, people use the offer to host tools and other people use these tools. Most people are friendly, the Toolserver is accepted by the Wikipedia-Communities (much more than WMDE or WMF), people think that the Toolserver is a good goal for donations, users and tool-users were most times very understanding if something didn’t work at first try or never at all, and WMDE was wise enough to not interfere much. The Toolserver developed MUCH better than I or anyone else predicted at the start, it is the most successful project WMDE ever started. At least for me "and more" is not possible. Sincerely, DaB.

Ryan Lane &lt;rlane(a)wikimedia.org&gt; wrote: The NDA isn't necessary. According to https://wikitech.wikimedia.org/wiki/Tool_Labs/Database_plan, the data set at the LabsDB stage is free of non-public data (modulo MariaDB accounts information which should probably not go off-site even with an NDA :-)). So we could (and IMHO should) provide DB dumps/bin logs at dumps.wikimedia.org or somewhere similar to anyone who can download them. Tim

On 17/09/13 00:11, Tim Landscheidt wrote: labs db server do contain the non-public data. It's just not viewable. So there aren't bin logs for just the non-public data. You *could* make a dump of the database (probably creating a new tool, as mysqldump would simply dump the view definition)... assuming you that in doing that you don't kill labs filesystem. ;)

On 17/09/13 01:22, Marc A. Pelletier wrote: I guess there could be a labs replica with triggers that deleted data at the point it became private, which could then serve as replication master providing public binlogs. The problem which breaks the idea completely are the restores, ie. non-public data coming back (the server would receive ‘show this again’, but it would need a full insert...).