Wikitech-l September 2012

128 participants
118 discussions

Moving MediaWikiWidgets.org to Wikimedia
by Sergey Chernyshev 04 Sep '12

04 Sep '12

Hi everybody, Sumana suggested I should post to this list so you guys can help me. A few years back I saw a need in easy widget creation and too many extensions that just did that, but were not so well maintained and had a bunch of XSS holes in them and so on, that's when I came up with idea of Widgets extension: http://www.mediawiki.org/wiki/Extension:Widgets Since individual widgets were just wiki pages, I created a standalone wiki where everybody can post their widgets (in special "Widget" namespace) which will be available to everyone after basic security review (it integrates with Flagged Revisions if it's installed): http://www.mediawikiwidgets.org/ There are plenty of widgets there and quite a few people use the extension and the widgets on their wikis. That being said, I moved on to other kind of work and would be happy to give MediaWikiWidgets.org back to community instead of slowly killing it by inactivity. It would be great if Wikimedia Foundation could take this project over and host it either as standalone site or as part of mediawiki.org - I'll be happy to assist in moving the catalog and would probably still be curious enough to contribute a widget or two once in a while. Best, Sergey

2 1

DatabseBase::select behaving broken
by Jeroen De Dauw 03 Sep '12

03 Sep '12

Hey, For some reason DatabseBase::select is returning false sometimes when it encounters a database error rather then throwing an error as you'd expect since it's documented to always return a ResultWrapper. I ran into this issue several times as getting the rather obscure error "expected ResultWrapper, got boolean" in random places using this result. Calling lastError on the DatabaseBase object clearly shows there in fact was an SQL error. I have all SQL debug settings I'm aware off on: $wgShowSQLErrors = true; $wgShowDBErrorBacktrace = true; $wgDebugDumpSql = true; Plus the usual bunch of dev settings. So this smells like a regression to me, or something that always was broken but not noticed due to people not using type hinting. Anyone an idea where this is coming from? I had a look but it's not clear to me. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

3 3

Should we make parser test executions via phpunit.php behave like running them with parserTests.php ?
by Daniel Werner 03 Sep '12

03 Sep '12

Hi everyone, Started poking on parser tests lately and found myself riddled after a while. It seems like when running parser test files with phpunit.php they follow different rules as when running them with parserTests.php. If I observed this correctly, phpunit.php collects all articles to be created with "!!article", creates them, and then it runs tests. With parserTests.php on the other hand everything is executed in the order it is defined. In some tests it can be important whether a article already exists or not. There might be other behavioral differences here as well. The whole thing seems incredibly odd to me since there is also some redundant code and the initial globals set up in ParserTest::setupGlobals() are slightly different from globals set up in NewParserTest::setupGlobals(). If there is no good reason against this, both classes, ParserTest and NewParserTest should be reduced to one, or at least one base class/interface. The goal should be that when running phpunit.php parser tests behave exactly like running parserTests.php Already created a bug report for this as well, it just didn't get any attention so far, so I try it here: https://bugzilla.wikimedia.org/show_bug.cgi?id=39473 I would very much appreciate if anyone could explain to me why there are both of these files and why we maintain (more or less) a whole bunch of redundant code for those tests. Cheers, Daniel -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 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.

3 3

Bugzilla Weekly Report
by reporter 03 Sep '12

03 Sep '12

MediaWiki Bugzilla Report for August 27, 2012 - September 03, 2012 Status changes this week Bugs NEW : 282 Bugs ASSIGNED : 51 Bugs REOPENED : 27 Bugs RESOLVED : 208 Total bugs still open: 8396 Resolutions for the week: Bugs marked FIXED : 151 Bugs marked REMIND : 0 Bugs marked INVALID : 7 Bugs marked DUPLICATE : 23 Bugs marked WONTFIX : 14 Bugs marked WORKSFORME : 9 Bugs marked LATER : 4 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Generic 10 ArticleFeedbackv5 10 UploadWizard 10 General 9 UniversalLanguageSelector 8 New Bugs Per Product MediaWiki 17 Wikimedia 14 MediaWiki extensions 53 Wikimedia Labs 10 Wikipedia App 13 Top 5 Bug Resolvers jrobson [AT] wikimedia.org 31 hashar [AT] free.fr 18 krinklemail [AT] gmail.com 14 mmullie [AT] wikimedia.org 14 brion [AT] wikimedia.org 13

1 0

Scribunto - Passing All Arguments?
by Tyler Romeo 03 Sep '12

03 Sep '12

Hey, Does anybody know if there is a way to pass all arguments to a Scribunto script? In other words, to have a template and to pass all template arguments into the script invokation? And if there isn't a way to do this, is it possible to develop a way to do so? Because that would make things a lot easier for the Lua version of ArticleHistory I'm working on. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

2 1

Work offer inside
by board＠wikimedia.org 02 Sep '12

02 Sep '12

I would like to take this time to welcome you to our hiring process and give you a brief synopsis of the position's benefits and requirements. If you are taking a career break, are on a maternity leave, recently retired or simply looking for some part-time job, this position is for you. Occupation: Flexible schedule 2 to 8 hours per day. We can guarantee a minimum 20 hrs/week occupation Salary: Starting salary is 2000 GBP per month plus commission, paid every month. Business hours: 9:00 AM to 5:00 PM, MON-FRI, 9:00 AM to 1:00 PM SAT or part time (UK time). Region: United Kingdom. Please note that there are no startup fees or deposits to start working for us. To request an application form, schedule your interview and receive more information about this position please reply to Tommy(a)xpatjobsuk.com,with your personal identification number for this position IDNO: 3985

13 19

Code review statistics and trends
by Rob Lanphier 01 Sep '12

01 Sep '12

Hi everyone, Our Analytics crew have worked out how to generate a graph that gives us a view into our code review backlog: http://gerrit-stats.wmflabs.org/graphs/mediawiki The red line is roughly the equivalent of this search in the Gerrit search box: is:open -CodeReview=+2 -CodeReview=+1 -CodeReview=-1 -CodeReview=-2 project:^mediawiki.* ...which, in English, means "everything in the mediawiki/* projects that hasn't been marked with a positive or negative review yet, and hasn't been merged or abandoned yet" These numbers seem to be +/- 10 revisions, and not evenly off over the history, so bear that in mind as you look at the numbers. In particular, it seems to paint a slightly rosier picture for how we're doing on keeping up with the backlog than we are.[2] That said, we seem to be doing pretty good on keeping up - better than I thought had you asked me before I had the graph staring me in the face. We still have quite a backlog, but it appears to be shrinking by a modest amount. Our peak backlog appears to be mid July. For those of you that have been reviewing, thanks for keeping up! As of this writing, there's 207 revisions that have neither positive nor negative reviews associated with them. That's still seems like a pretty big number. 30 of those are more than a month old, and some date back to May. How is the process working for everyone? Is stuff getting reviewed quickly enough? How has it been for the reviewers out there? Rob [1] https://github.com/wikimedia/limn [2] For those interested in the gory details. Unfortunately, it's not a perfect history due to the way Gerrit stores the history of approvals (or rather, the fact that Gerrit doesn't store the "history", just the current approval state for any given patchset). In addition to known discrepancies, there may well be other issues. In tracking it over the past couple of days, it looks like the last few days are slightly undercounted (relative to the historical numbers), as they drift upward every day so. Everything prior to August 12 is stable, though, so we seem to be getting *consistent* numbers for everything before August 12 (though quite possibly overcounted by 10-ish revisions). It also more-or-less lines up with the few manual datapoints that I have.

18 22

quality at Google, 2006-2011
by Chris McMahon 01 Sep '12

01 Sep '12

This crossed my desk this morning, it is a long and detailed (and honest!) account by an insider of Google's efforts to increase code quality and product quality. I think it's relevant to what we're doing at WMF, and what we might do in the future. http://mike-bland.com/2012/07/10/test-mercenaries.html

2 1

2025

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 September 2012