Wikitech-l July 2013

wikitech-l@lists.wikimedia.org

158 participants
162 discussions

quarterly review notes from Engineering Community Team
by Sumana Harihareswara 23 Jul '13

23 Jul '13

Agenda and minutes from the second quarterly review of the Engineering Community Team: https://www.mediawiki.org/wiki/Volunteer_coordination_and_outreach/ECT_July… Some highlights: * The Community Liaisons (coordinated through the Legal & Community Advocacy group) will continue to work on specific big changes that require a lot of communication and feedback facilitation, such as VisualEditor, Flow, and some mobile changes. Engineering Community Team will continue to support communication about smaller deployments and about general engineering activity. * We're cautiously optimistic about helping volunteers learn to write more automated browser tests for gadgets, to reduce breakage. Chris McMahon has just started: http://lists.wikimedia.org/pipermail/qa/2013-July/000198.html * Now that Tool Labs users can use replicated databases, I need to reassess the pain points of current and potential users. I anticipate we'll learn some of that during the documentation sprint this week: http://lists.wikimedia.org/pipermail/labs-l/2013-July/001428.html I was remiss and did not publicize the first of the ECT quarterly reviews, which took place in February; agenda and minutes are here: https://www.mediawiki.org/wiki/Volunteer_coordination_and_outreach/ECT_Feb_… You can keep up on our work more frequently here: https://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering#Engineering_C… and you can read about our goals for the next year here: https://www.mediawiki.org/wiki/Wikimedia_Engineering/2013-14_Goals#Wikimedi… Thank you. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

1 0

draft goals for Engineering Community Team for the next 12 months
by Sumana Harihareswara 23 Jul '13

23 Jul '13

https://www.mediawiki.org/wiki/Wikimedia_Engineering/2013-14_Goals#Wikimedi… The Engineering Community Team has some draft goals for what we'd like to achieve in the next 12 months. We'll still be running Bugzilla, putting out the monthly report, running GSoC and OPW, and doing those other continuous tasks (as you can follow at https://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering#Engineering_C… ). But what else should we be concentrating on? This is a draft of what we'd like to focus on, quarter by quarter. Some highlights: * Getting more volunteers trained in writing automated tests, especially so that we can fix problems quicker in more Wikimedia functionality (including important gadgets) * Growing Tech Ambassadors membership, to improve two-way communication between developers and users * Training more volunteers in JavaScript and security-related development and code review, to improve bottlenecks I welcome your comments here or on the talk page. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

4 6

MediaWiki extensions as core-like libraries: MediaWiki's fun new landmine for admins
by Ryan Lane 22 Jul '13

22 Jul '13

I attempted to install Wikibase the other day and made a fun discovery. Installing it properly requires the following (12) extensions: WikibaseClient Wikibase DataModel WikibaseLib Wikibase Repository DataValues DataTypes ValueParsers ValueView ValueValidators ValueFormatters Diff Scribunto And the following optional (2) extensions: Universal Language Selector Babel Soon it will also require at least the following (4) extensions: Ask Wikibase Query Wikibase Database Wikibase QueryEngine To fully deploy wikibase in a way that will work like wikidata, it will take at least 18 extensions, all of which are versioned differently, and are broken out in this manner to be used as libraries. What this is subtly doing is adding another dependency chain into MediaWiki: extension libraries. Since these extensions are meant to be used as libraries, other extensions will eventually do so and admins will have to worry about not only extension compatibility with MediaWiki (an already nearly impossible task), but will also need to worry about extension dependency with extension libraries. The compatibility matrix for this is going to be terrible and exacerbates one of MediaWiki's biggest problems for admins. Quite a few of these should be core functionality or if they can't properly pass review they should be removed. For legitimate library-like extensions I have no constructive alternative, but there must be some sane alternative to this. - Ryan

11 49

Goodbye gerrit-wm, welcome lolrrit-wm!
by Yuvi Panda 22 Jul '13

22 Jul '13

(The bot is temporarily being called lolrrit-wm instead of gerrit-wm until we get some issues fixed. lolrrit-wm is not a permanent nick for the bot!) Hello! The old gerrit-wm was a bunch of python scripts running as hooks in the production cluster, which were hacky and not too well maintained. Chad asked me if I could write a replacement, and since I already had some infrastructure for similar tools running on toollabs, I wrote one. The source is at https://github.com/yuvipanda/lolrrit-wm, and will be moved to Gerrit soon. It's currently running on toollabs, with me and ^demon as co-maintainers. The new one is now active wherever the old one is supposed to be. If it is not reporting changes somewhere it should be, please ping me so I can fix that. It has a cleaner message format that also packs more info into it, and hopefully can be more useful and less spammy. Feature requests and pitchforks welcome! And requests/ideas for other similar tools are also welcome :) -- Yuvi Panda T http://yuvi.in/blog

2 3

What's the best way to identify actually executed MediaWiki extensions?
by Adam Baso 22 Jul '13

22 Jul '13

A friend of mine asked me what's the best way to identify actually executed MediaWiki extensions, not just the ones that are installed. Any hints? I thought that enabling debug logs for a day, then grepping for the text of filenames in the directory 'extensions' (subtracting out the stuff that adds hooks to the registry on page load only) may do the trick. But I imagine there are other wrinkles, and was hoping someone had a canned technique. -Adam

3 4

Re: [Wikitech-l] Request for Comments: New Search
by Robert Elwell 22 Jul '13

22 Jul '13

Hi Nik, Just a quick comment on choosing ElasticSearch over Solr: We use Solr at Wikia, and we have a lot we can offer the Foundation in terms of knowledge sharing. It might be a good idea to consider future opportunities to collaborate while vetting ElasticSearch. Even if ElasticSearch is your final call, you may still be able to use some of the code from our Search extension (https://github.com/wikia/app/tree/dev/extensions/wikia/Search). It uses the Solarium library for query abstraction, and I'm wondering if adding ElasticSearch support to that library and starting with some of the libraries we've written might get you most of the way there in your CirrusSearch efforts. And code aside, both solutions have very similar engines behind them. When it comes to generating schemata, analyzing fields, handling language support, scaling, or backend architecture, please feel free to reach out. We'd love to help. Robert Elwell On Jul 19, 2013, at 5:14 PM, Rob Lanphier <robla(a)wikimedia.org> wrote: > Everyone, > > I'm reviving this old thread to update everyone on the status of the RFC: > > We've continued working on implementation and everything seems to be > proceeding smoothly. We evaluated Elasticsearch and were super impressed > and decided it was very likely to be worth switching from Solr4 to it. The > evaluation and the switch did cost some time but in my opinion doing it was > time well spent. > > Thanks so much for your comments a month ago when I first posted this. If > you are interested please give the page another look. Just to be helpful, > here is a link to what I changed: > http://www.mediawiki.org/w/index.php?title=Requests_for_comment%2FCirrusSea… > > Nik Everett

1 0

Request for Comments: New Search
by Nikolas Everett 22 Jul '13

22 Jul '13

So Chad and I feel like we've gotten far enough in our prototype of our new search backend for MediaWiki that we're ready to request comments. So here is our format RFC: https://www.mediawiki.org/wiki/Requests_for_comment/CirrusSearch You'll note that the plugin is called CirrusSearch. SolrSearch seems to have been taken by an unrelated project so we had to pick a different name. Please read and comment in whatever way is normal for these things. Thanks so much for your attention, Nik Everett

2 4

Bugzilla Weekly Report
by reporter 22 Jul '13

22 Jul '13

1 0

Alternative editor?
by Derric Atzrott 21 Jul '13

21 Jul '13

Good day, Now I finally do have a question that might make some sense. I'm attempting to replace the editor for Mediawiki for certain pages. Are there any examples of how to use the AlternateEdit hook beyond looking at the code for Mediawiki itself? Are there any extensions that make use of this hook? Does VisualEditor? I just want a second example of how to build an edit page that does things a little differently so that I can compare the two and learn a bit more about ways that I can go about this. Thank you, Derric Atzrott Computer Specialist Alizee Pathology

3 2

Git Proxy Error
by planetenxin 21 Jul '13

21 Jul '13

Hi folks, I'm constantly getting the following error on https://git.wikimedia.org/: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /. Reason: Error reading from remote server /Alexander

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l July 2013