Wikitech-l February 2011

wikitech-l@lists.wikimedia.org

111 participants
73 discussions

Another 1.17 maintenance window
by Rob Lanphier 16 Feb '11

16 Feb '11

( repost from http://techblog.wikimedia.org ) Continuing with the work started last week[1], we plan to deploy 1.17 to more wikis in a couple hours. We had hoped we would be able to figure out the performance issues in the past week, but unfortunately, the only practical way we have to see the load problems we witnessed last week is to put the software into production. We have put a lot of instrumentation in place to help us diagnose our load issues. We plan to start the upcoming deployment by rolling out to nl.wikipedia.org, and do some debugging (rolling back if necessary). If we’re able to diagnose and fix the problems quickly, we then plan to roll out 1.17 more widely. If we’re still stumped, we may still roll out to a few more low-traffic wikis, but leave the high-traffic sites until we figure this out. We plan to have more updates and detailed information on the deployment page on mediawiki.org[2]. Thanks for your patience! Rob [1] http://techblog.wikimedia.org/2011/02/1-17deployment-attempt2/ [2] http://www.mediawiki.org/wiki/MediaWiki_1.17/Wikimedia_deployment

4 3

Making code review happen in 1.18
by mhershberger＠wikimedia.org 16 Feb '11

16 Feb '11

The problem with our current VCS is the sort of work-flow that has developed around it. But we can solve the work-flow problem without introducing an entirely new VCS and disrupting everything for a month or so while people adjust to the new system. The solution I'm proposing is that we branch 1.18 immediately after the release of the 1.17 tarball. Revisions marked “OK” (or, perhaps, tagged “118”) on the trunk could be merged to the 1.18 branch. Or, to make merging into 1.18 less of a chore for a single person, we could enable those doing code review to merge code they've reviewed into the 1.18 branch. In this way, we achieve Roan's (and my) goal of continuous integration. This also put the onus on the individual developers to make sure that their code gets reviewed and that problems found get fixed. As a bonus, we could set a date *now* to make the 1.18 release and then just release whatever is in the 1.18 branch on that day. I think we need a few goals thrown in to make this really good — I propose “1.18 will include a web UI for configuring MediaWiki” and “1.18 will cut the number of global variables in half” to pick two of my personal favorites — but I think the work-flow of how MediaWiki is prepared for release needs to be addressed. Mark.

18 30

Roadmaps and getting and keeping devs
by David Gerard 16 Feb '11

16 Feb '11

These have been circulating in the open source Twitterspere today. They struck me as apposite to discussions on these topics around MediaWiki. How to write a roadmap: http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/ How to grow your contributor community (and how to decimate it): http://www.codesimplicity.com/post/open-source-community-simplified/ - d.

21 52

strange page id numbering
by Anthony Ventresque (Dr) 16 Feb '11

16 Feb '11

Hi, I've found something strange in some files. The maximum ids for a page are: latest pages-articles.xml: 29189922 page.sql: 28707562 categorylinks.sql: 28705949 (15,684 categories and 135,521 articles are missing) 2011-01-15 pages-articles.xml: 30492297 page.sql: 30480288 categorylinks.sql: 30479519 Any idea why these numbers are different? Thanks for your help, Anthony CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its content. Thank you. Towards A Sustainable Earth: Print Only When Necessary

6 8

The mobile site
by mhershberger＠wikimedia.org 16 Feb '11

16 Feb '11

I talked to Hampton yesterday about the current Mobile site and, since it was discussed here recently, I thought I'd try to update you all on what he told me. First, Hampton mentioned that while he, personally, isn't doing any work on the Mobile rewrite (I think Tomasz Finc is trying to find someone to do that), but he is still doing things like * Adding new Wikis to the mobile proxy (e.g. https://bugzilla.wikimedia.org/27290) At his request, I will be adding the keyword “mobile-lang” to these requests so that he can group them together * Adding support for new UserAgent strings (e.g. https://bugzilla.wikimedia.org/27257) He can update the mobile proxy's support, but will need to rely on CSS files provided by the community since he can't test all devices. Note that Hampton cannot do things like adding new features (e.g. https://bugzilla.wikimedia.org/25119) because of the PHP re-write. Mark.

1 0

categorisation issues in dumps
by Anthony Ventresque (Dr) 15 Feb '11

15 Feb '11

Hi, I am trying to build an offline version of the wikipedia categorisation tree. As usual with projects on wikipedia, I've downloaded dumps (actually the interesting one here is pages-articles.xml). And I found that none of the dumps has the relation between "Category:1960_works" and "Category:1960" which is present on the web page. And it is the same for a lot of categories I tried: many links are missing in the dump, but are present in the web. Any idea why is that so? Thanks for your help, Anthony CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its content. Thank you. Towards A Sustainable Earth: Print Only When Necessary

2 2

Status of mobile site rewrite
by MZMcBride 15 Feb '11

15 Feb '11

Hi. There are a few open bugs about adding mobile site support to a specific Wikimedia wiki. For example, bug 27290 is about creating a mobile main page for fa.m.wikipedia.org.[1] What's the status of the mobile site / mobile site rewrite?[2] I'm mostly curious because I think these open bugs can be made a dependency of the rewrite bug, but that's only really true if development work has stopped on the current mobile site implementation. I think I read that work had stopped in a bug comment at some point (or at least it was intimated), but I'm not sure. Does anyone know what the current status is? MZMcBride [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=27290 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=25558

3 2

[ResourceLoader] JavaScript may break on your wiki: Fix it before that happens
by Guillaume Paumier 15 Feb '11

15 Feb '11

Greetings, As you may know, the Wikimedia teach team has started to upgrade MediaWiki on some wikis. MediaWiki is the software that runs all Wikimedia wikis. The most visible change for Wikimedia users will be the deployment of ResourceLoader [1]. ResourceLoader optimizes the use of JavaScript in MediaWiki, speeding up its delivery by compressing it sometimes, and cutting down on the amount of unused JavaScript that gets delivered to the browser in the first place. The installation of ResourceLoader may cause compatibility issues with existing JavaScript code. Trevor Parscal and Roan Kattouw, the main developers of ResourceLoader, will be available on IRC [2] on Monday, February 14th, at 18:00 (UTC) [3], to answer questions and help fix issues related to ResourceLoader. *If you maintain JavaScript code on your home wiki, please attend.* Don't wait until your wiki's JavaScript is all broken. Please spread this information as widely as possible; it's critical to reach as many local JavaScript maintainers as possible. Logs of the session will be published publicly. [1] http://www.mediawiki.org/wiki/ResourceLoader [2] http://meta.wikimedia.org/wiki/IRC_office_hours [3] All timezones: http://ur1.ca/3819u -- Guillaume Paumier Product manager - Wikimedia Foundation Support free knowledge: http://donate.wikimedia.org

6 10

Switch mediawikiwiki to 1.17wmf1
by Krinkle 15 Feb '11

15 Feb '11

Hi, While working on fixing gadgets etc. I just noticed mediawiki.org itself was not part of the first wave (I confused it with metawiki I guess). Is there any issues with switching to 1.17wmf1 before the rest goes (say tonight or Monday) ? Currently I'm writing some documentation but the 'new' versions of things don't actually work on mw.org so it's hard demonstrating it, since it won't work on mediawiki.org I could move things to Meta-Wiki and back again, but since mw.org is a relatively small wiki I think there wouldn't be any load issues (is that still an issue?) in switching it before the 'final wave'. The reason I'm writing these things now instead of Wednessday is because A) Some wikis are already switched and they're screaming about broken gadgets which need updating. Since these gadgets are usually copied from MW.org fixing them there now results in them being broken on MW.org B) I like to get things ready before the actual switch is made so that when the switch is made, people can update things right away. -- Krinkle

5 5

Patch catch-up: bug 23817 fixes committed
by Brion Vibber 14 Feb '11

14 Feb '11

To start out with catching up on patch review, I took a look over and applied the patches on bug 23817, fixing wfObjectToArray() and FormatJson for a case that broke certain parts of ForeignAPIRepo when PHP's native JSON module wasn't present: https://bugzilla.wikimedia.org/show_bug.cgi?id=23817 The patches were posted by Tim Yates shortly after his bug report in June 2010; the same bug was re-filed in December as bug 26250, and only reconnected later. Thanks for the fix, Tim! -- brion

2 1

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