Wikipedia:Wikipedia Signpost/2012-01-23/Technology report

MediaWiki 1.19 preview
Developers working on MediaWiki 1.19, the latest version of the software on which Wikimedia wikis run, are now welcoming beta testers (as announced, for example, on Wikimedia Commons' village pump). According to the release's page on MediaWiki.org, it will feature improvements to the distribution of CSS styling, block log searching, timezone recognition and diff readability (as previously reported); and increased support for different relational database management systems and different languages and scripts. Over a hundred bugs are also expected to be fixed in the release (a reasonably comprehensive list of these is available).

The lengthened testing period (and more generally, the broadness with which testing is being carried out) is designed to head off the kind of implementation problems that have marked previous deployments. Work on reviewing the 1.19 code prior to deployment slowed this week, under the burden of SOPA blackout preparations. As a result, the January 31 deadline for code review will almost certainly be missed; at time of writing, 177 revisions are still in need of review compared to the target of just 44 (full chart).

The importance of 1.19 could well extend beyond its actual deployment; it is currently slated as the final SVN release before a faster, Git-based release cycle kicks in (details). As such, how well the existing process functions is likely to significantly influence the many choices that will be made during the migration to Git.

JavaScript problems ahead?
Another problematic issue of interest to wikitech-l regulars this week was referenced in a short exchange between staff developer Timo Tijhof (better known by his alias Krinkle) and bugmeister and general development process overseer Mark Hershberger. The issue centres on the tricky matter of the correct balance between backwards compatibility and modernisation in the realm of JavaScript loading.

Since the introduction of ResourceLoader in MediaWiki 1.17, core scripts and (some) gadgets are loaded as 'modules'. One of these modules is 'mw.util', on which many user scripts now rely for proper operation. The problem has arisen because, in the past, little effort was made to economise the loading of these modules, and they were assumed to be present when another script needed them (including Common.js). For the past 18 months, however, much more time has been devoted to streamlining the loading process, allowing for faster loading times and a reduced physical footprint for each page: a boon for those on slow Internet connections.

However, this improvement makes it necessary for scripts and script writers to declare which modules their script relies on (known as 'dependencies'). Officially, this has been mandatory since the introduction of ResourceLoader, but until now, these modules were already loaded by other core scripts, allowing scripts to run without errors.

Many scripts have been, or will need to be, updated to conform to the ResourceLoader specification, however. That is ultimately where the problem of backwards compatibility comes in: how to transition to the new standard while not breaking functionality of existing scripts, particularly on smaller wikis that could have lain untouched for years. "If we upgrade MediaWiki and we know that people are going to complain because a widespread dependency (like mw.util) disappeared, let's [avoid making that happen]" wrote Hershberger, "[Nobody wants a] horribly shocking experience after we upgrade the cluster". The best way to achieve that without largely nullifying the performance gains from modernisation is still being discussed (see this bug report).

In brief
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks.
 * Brief period of slowness traced to Varnish: For about 15 minutes on 20 January, American viewers experienced unstyled pages, drastically increased page loading times, or both. The problem was soon traced to the Ashburn servers responsible for serving bits.wikimedia.org requests (a heading that incorporates styling information, various global scripts, and similar kinds of content). It seems that work being performed to an unrelated intermittent fault, combined with a bug in the Varnish accelerator in use on the servers, resulted in the latter rapidly spiraling out of control. Traffic was temporarily redirected to the servers located in Tampa, an action that could become automated in future.
 * librsvg upgraded: The version of the librsvg used on Wikimedia wikis was upgraded on 23 January to capture improvements made to its implementation of CSS styling. Wikimedia's relationship with the SVG-to-PNG conversion software (generally regarded as the only such software efficient enough to be viable for Wikimedia wikis) has traditionally been love-hate, with users often having to work around its quirks (tracked as bug #31122).
 * "Tabletisation" of Wikimedia apps: As discussed by Lead Software Architect Brion Vibber on his personal blog, efforts have started to reformulate the code behind the Wikimedia iOS and Android apps to allow them to work properly on tablets such as iPads and Kindle Fires. Both transitions are still in their early stages.
 * MediaWiki extension pages to be reviewed: According to a post on the wikitech-l mailing list, a group of developers will attempt to update the main documentation pages of all two thousand MediaWiki extensions registered on MediaWiki.org. The work will assist "future drives reviewing actual code of extensions". Improved documentation is also likely to help external wiki operators considering upgrading their MediaWiki installations.
 * Interwiki bots to merge: Following statistics demonstrating the high percentage of Toolserver resources being taken up by interwiki bots, the toolserver-l mailing list was dominated by discussions over a possible merger to concentrate efforts and make them more efficient. Non-Toolserver bots would be unaffected, but additional Toolserver bots may be prevented.