Looking ahead to MediaWiki 1.19 and related issues
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.
Discuss this story
Just a small clarification I wanted to make though
The above quote is not entirely correct. Gadgets that were written before the introduction of ResourceLoader will not be affected since modules didn't exist back then, therefor they won't be affected by anything related to "dependencies" since they do not use any modules.
This matter only concerns modules created by MediaWiki extensions (including Gadgets that are using "
[ResourceLoader]" in their definition). And from those only the ones that are referring to a module in their code (such asmw.utilor$.ui.dialog) without adding the name of this module as a "required" for their module (which is done by the "dependencies=" option (more info)).Imagine a module A and B both use "jquery.ui", but only module A has this requirement declared in it's meta-data. Before MediaWiki 1.19 modules used to load a bit slower, so loading A and B (in that order) would probably not fail because B happens to be loaded after module A which already provided the "jquery.ui" functionality. In MediaWiki 1.19, however, modules are loading faster and thus make it less likely for these "lucky" hits to occur.
We acknowledge that these "lucky" hits were more common than they should be and some users have come to expect that certain modules would simply be available by default, to aid the transition we've loaded some the most popular modules by default (such as
mw.util), however other than that there isn't a whole lot we can do since there is no way of knowing which modules are needed, this is exactly where "dependencies" is for. From looking around however I see that most gadgets that use modules do have their dependency meta-data in order, it's mostly the simple few-line gadgets that emerged from copy/pasting code without including the dependency information formw.util.If anyone runs into ResourceLoader dependency-related issues on wikis in beta@wmflabs or here live post-deployment, I'd recommend you report it to mw:Talk:ResourceLoader/Migration guide (users). Krinkle (talk) 16:04, 12 February 2012 (UTC)[reply]