Wikitech-l June 2011

wikitech-l@lists.wikimedia.org

116 participants
112 discussions

Re: [Wikitech-l] New Employee Announcement - Jeff Green
by Roan Kattouw 30 Jun '11

30 Jun '11

On Thu, Jun 30, 2011 at 11:19 PM, CT Woo <ctwoo(a)wikimedia.org> wrote: > All, > Please join me to welcome Jeff Green to Wikimedia Foundation. Welcome! Yay ops! > He and his family > will be moving back to Massachusetts this August. Is this a typo or is Jeff really taking a job in SF and moving to the other side of the country a month later? Roan Kattouw (Catrope)

1 0

Re: [Wikitech-l] New Employee Announcement - Jeff Green
by Erik Moeller 30 Jun '11

30 Jun '11

On Thu, Jun 30, 2011 at 2:19 PM, CT Woo <ctwoo(a)wikimedia.org> wrote: > Please join me to welcome Jeff Green to Wikimedia Foundation. > Jeff is taking up the Special Ops position in the Tech Ops department where > one of his responsibilities is to keep our Fundraising infrastructure > secured, in compliance with regulation, scalable and highly available. Jeff > comes with strong systems operation background especially in scaling > and building highly secured infrastructure. He hails from Craiglist where he > started as their first system administrator and served as their lead system > administrator as well as their Operations manager, most of his tenure > there. Welcome to the team! :-) -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

1 0

Domain name for cruisecontrol
by Bryan Tong Minh 30 Jun '11

30 Jun '11

Can we have a proper domain name for cruisecontrol? Something like testing.mediawiki.org. That is much easier to remember than ci.usability.tesla.wikimedia.org or whatever.

3 2

Report from yesterday's IRC Bug Triage
by mhershberger＠wikimedia.org 30 Jun '11

30 Jun '11

This week's bug triage was the first one held by IRC in an effort to be more open to community involvement. On that basis, it was successful: User:Bawolff stepped up to the plate to take on a couple of bugs and User:Leinad stepped in to ask us to consider solving Bug #29170. In preparation for 1.18, I had taken all of the bugs marked with “High” priority and made them blockers on the 1.18 Deployment Bug (https://bugzilla.wikimedia.org/29068) or on the 1.18 Tarball Bug (https://bugzilla.wikimedia.org/28425). So the first thing we did was look at this list of blocker bugs and make sure they all should be blockers. This process revealed a problem with my method of turning “High” priority bugs into blockers for release. For example, I didn't examine some bugs closely enough. The following two are a good example of this: https://bugzilla.wikimedia.org/14890 Make image views statistics available through Wikistats https://bugzilla.wikimedia.org/28898 Set up notification for when/if Google's safe browsing spots something on wiki Others that we found and removed from being blockers were https://bugzilla.wikimedia.org/18861 Search should index template expansion https://bugzilla.wikimedia.org/25404 lucene search for simple text misses some results https://bugzilla.wikimedia.org/28223 iPhone Native Crash with UTF-8 https://bugzilla.wikimedia.org/28485 Block::purgeExpired giving "Lock wait timeout exceeded;"/"Deadlock" https://bugzilla.wikimedia.org/28543 Article::updateCategoryCounts 1213 Deadlock found when trying to get lock https://bugzilla.wikimedia.org/28700 Make upload.wikimedia.org Cross Origin compatible (CORS) https://bugzilla.wikimedia.org/28862 Javascript not working for blackberry show/hide section collapse disabled Going through the list also helped us discover a couple that should be closed WORKSFORME: https://bugzilla.wikimedia.org/28857 Sometimes there's "undefined" in a Resource loader CSS request https://bugzilla.wikimedia.org/29234 Prevent creation of new (unattached?) SUL accounts with already unified names >From there, we moved on to the bugs that were affecting people right now. https://bugzilla.wikimedia.org/29277 MediaWiki:Filepage.css not loaded on foreignwiki itself Chad glommed onto right away. After a bit of diagnosis, he fixed it this morning (http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91031). https://bugzilla.wikimedia.org/29552 Edited page is not showing the most recent edits to anyone not logged into wikipedia Bawolff has been working on the problem and, upon Robla's advice, I bumped the priority. Bawolff may need some help figuring out how to test Squid, but until he does, he's on it. https://bugzilla.wikimedia.org/29585 maintenance script edit.php doesn't update link tables properly Since Bawolff was already working on this and it was otherwise a low priority, I assigned it to him. https://bugzilla.wikimedia.org/29021 Anonymous users can edit page protected with [edit=autoconfirmed] Roan suggested that the page may have been deleted and undeleted, thus removing the edit protection. This suggestion led to close examination of the log where Brion notice today that everything was,in fact, working correctly, but, because of difficulty on the part of the developers in understanding the timeline and the actions, that wasn't seen soon enough. https://bugzilla.wikimedia.org/27478 Enable $wgHtml5 on Wikimedia wikis There were no known technical issues blocking this, but in order to avoid having to roll it out and then roll it back when people complained that it broke, say, Twinkle, we needed to make sure we have someone who can babysit the roll out. After some discussion, We appointed Reedy to be the point man on this. https://bugzilla.wikimedia.org/29495 India-style commas This request from Indian wikis and a clear description of the tasks involved from Brion made it a great addition to our “Annoying little bug” page (http://www.mediawiki.org/wiki/Annoying_little_bug) that I'm maintaining to point potential new MediaWiki developers to some relatively achievable tasks. https://bugzilla.wikimedia.org/29564 LQT putting crap in dumps By the time we got to this in triage, Brion already had a fix committed for this one. Yay, Brion! https://bugzilla.wikimedia.org/15434 - Periodical run of currently disabled special pages (WantedPages, WantsTemplates etc.) After Tim pointed out that a few of the disabled pages “should never be run under any circumstances”, I asked him to update the bug with information about which of the queries that was. https://bugzilla.wikimedia.org/29170 [[MediaWiki:Enotif body]] needs GENDER support As if Bawolff's involvement in the triage wasn't reason enough to continue holding them on IRC, Leinad stopped by during the meeting to ask if we could fix this bug for the 1.18 release. After a bit of discussion, we decided that I should contact the author of enotify to see if he would fix gender support. That's all for this week. Our next IRC triage will be at 2100 UTC Wednesday. I hope to see you there, Mark.

2 1

Google Chrome
by James Heilman 30 Jun '11

30 Jun '11

I am having some difficulties editing with Google Chome. The browser adds extra spaces with many edits and is unable to add lines to the middle of infoboxes (when you hit the enter key it just moves you to the bottom of the infobox code). I am not sure if this is a chrome problem or a wiki problem. I do wish to get a chrome book but unless this can be addressed it will just cause me frustration. -- James Heilman MD, CCFP-EM, Wikipedian

3 2

Wikimedia repository gets CodeReview tool and a fancy 'commits' mailing list
by Arthur Richards 30 Jun '11

30 Jun '11

Hi everyone, A while back we set up a 'Wikimedia' SVN repository [1] (as opposed to the 'Mediawiki' SVN repository [2]) to hold Wikimedia-related yet non-MediaWiki related code. This has been great particularly for miscellaneous fundraising-related code as well as our instance of CiviCRM and associated modules. I wanted to give a big thanks to Sam Reed and Casey Brown who earlier this week helped set up a 'Wikimedia-commits' mailing list. If you're interested in following along with commits to the Wikimedia repo, feel free to subscribe [3]. Reedy also helped get the CodeReview tool set up for the repo [4] which is going to help us a great deal with following similar code review conventions as with the MediaWiki repository. So yeah, thanks! Arthur [1] http://svn.wikimedia.org/viewvc/wikimedia/ [2] http://svn.wikimedia.org/viewvc/mediawiki/ [3] https://lists.wikimedia.org/mailman/listinfo/wikimedia-commits [4] http://www.mediawiki.org/wiki/Special:Code/Wikimedia -- Arthur Richards Software Engineer Fundraising/Features/Offline/Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687

2 1

Reproducing localurl by python urllib.quote()
by Alex Brollo 29 Jun '11

29 Jun '11

I found a number of troubles when trying to replicate localurl: parser function by python urllib.quote(), with a number of annoying bugs. Is this correct-complete? "/wiki/"+urllib.quote(name-of-page.replace(" ","_"),"/!,;:.-_") where name-of-page is utf-8 encoded. Thanks! I apologyze for so a banal question. Alex brollo

4 6

Code review stats (was Re: Code Review for 1.18)
by Rob Lanphier 29 Jun '11

29 Jun '11

On Wed, Jun 29, 2011 at 10:19 AM, Ashar Voultoiz <hashar+wmf(a)free.fr> wrote: > You gave me the git repo at one point. Still haven't managed to look at > the code and enhance it. Maybe we could add it to the subversion > repository and have volunteers enhance it. Here's the repo: https://gitorious.org/mwcrstats/mwcrstats On Wed, Jun 29, 2011 at 10:22 AM, Chad <innocentkiller(a)gmail.com> wrote: > Even cooler would be integrating this into CodeReview itself, > perhaps alongside what we have [here:] > http://www.mediawiki.org/wiki/Special:Code/MediaWiki/stats That would be cool. The code I wrote is in Python, so it would need to be ported PHP. I took an approach that gave me a lot of flexibility, but it also made things a little complicated. Bryan Tong Minh's approach may be a better starting point for the data generation part. I don't remember where he posted the queries he uses, but I'll post them here now: mysql -hsql-s3 mediawikiwiki_p -e"SELECT MAX(cpc_timestamp) AS ok_timestamp FROM code_rev JOIN code_prop_changes ON cpc_repo_id = 1 AND cpc_rev_id = cr_id WHERE cr_repo_id = 1 AND cr_status IN ('ok', 'resolved') AND cr_path LIKE '/trunk/phase3%' GROUP BY cr_id ORDER BY ok_timestamp ASC" -N >code_ok.txt mysql -hsql-s3 mediawikiwiki_p -e"SELECT cr_timestamp FROM code_rev LEFT JOIN code_prop_changes ON cpc_repo_id = 1 AND cpc_rev_id = cr_id WHERE cr_repo_id = 1 AND cr_status IN ('ok', 'resolved', 'fixme', 'new') AND cr_path LIKE '/trunk/phase3%' AND (cpc_rev_id IS NOT NULL OR cr_status = 'new') GROUP BY cr_id ORDER BY cr_timestamp ASC" -N >code_all.txt Nimish and Erik Zachte are in the process of working on some jqPlot-based reporting tools, and it might be best to leverage their work rather than using Flot (which is what my code uses). jqPlot is a fork of Flot, from what I understand, so much of what is possible in Flot should also be possible in jqPlot. Some more info on that is here: http://www.mediawiki.org/wiki/Wikimedia_Report_Card_2.0 ...and http://www.mediawiki.org/wiki/Wikimedia_Report_Card_2.0/status Rob

2 1

Sortable tables broken in 1.18 & trunk; needs tests & fixes or revert
by Brion Vibber 29 Jun '11

29 Jun '11

The sortable table system in MediaWiki was completely rewritten in r86088; unfortunately this was done without benefit of any unit testing or regression testing, and there seem to be a lot of new bugs introduced. I've started adding test cases for table sorting in r90595; this adds a qunit test suite that creates some short tables (listing planets Mercury through Saturn and their radii) and tries setting up and triggering sorting, then compares the resulting order to the expected value. The ascending sort by name usually works, but if called twice on two tables, the second table usually gets sorted *completely* incorrectly. This can be easily confirmed by manual inspection by copying a page such as http://test.wikipedia.org/wiki/Planets_of_doom to your trunk wiki and sorting first one table, then the other. Numeric sorting on the radius column is also incorrect; the data set includes values with two different orders of magnitude (> 10k and < 10k), and they don't sort correctly. You can confirm on the test.wikipedia page that these sort as expected in 1.17. These specific bugs will also need to have test cases added, all of which are claimed to be fixed by r86088 or its follow-ups: * https://bugzilla.wikimedia.org/show_bug.cgi?id=8028 * https://bugzilla.wikimedia.org/show_bug.cgi?id=8115 * https://bugzilla.wikimedia.org/show_bug.cgi?id=15406 * https://bugzilla.wikimedia.org/show_bug.cgi?id=17141 * https://bugzilla.wikimedia.org/show_bug.cgi?id=8732 * https://bugzilla.wikimedia.org/show_bug.cgi?id=28775 As a reminder, you can run the qunit tests from your browser by simply going to the tests/qunit/ subdirectory of your wiki installation. General info: http://www.mediawiki.org/wiki/Manual:JavaScript_unit_testing -- brion

5 6

Code Review for 1.18
by mhershberger＠wikimedia.org 29 Jun '11

29 Jun '11

The number of un-reviewed revisions for 1.18 has dropped below 500 for all of /trunk and below 200 for phase3: mysql> select count(*),cr_status from code_rev where cr_repo_id = 1 \ and cr_id > 47450 and cr_id < 87529 and cr_path like \ '/trunk%' group by cr_status; +----------+-----------+ | count(*) | cr_status | +----------+-----------+ | 13951 | deferred | | 82 | fixme | | 339 | new | | 16534 | ok | | 1240 | old | | 1585 | resolved | | 793 | reverted | +----------+-----------+ 7 rows in set (0.06 sec) mysql> This is great news! >From this and <http://toolserver.org/~robla/crstats/crstats.118all.html>, It looks like we *could* drive the number of “new” revisions to 0 by the end of the week. That would be stunning. Mark.

6 7

2026

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 June 2011