Major strands of development cycle coalesce as 1.19 is deployed to first wikis
1.19 deployment runs into trouble almost immediately
Over three days in the middle of the week, MediaWiki 1.19 went live to its first twelve (Wikimedia) wikis (a spread of different types of project including Wikisources, two Wikipedias, a Wikiquote, a Wikiversity and Meta). As expected, the deployments shed light on a number of issues with the release, including the appearance of a number of bugs that needed fixing before the planned rollout to Wikimedia Commons on February 21 (an up-to-date list of such bugs and their statuses is available).
For example, developers are currently wrestling with a number of JavaScript-related issues, including a problem (filed as bug #34409) which resulted in certain core variables not being defined. Since other scripts relied upon these variables (mw.user.options and mw.user.tokens), end users quickly reported problems with their watchlists and user gadgets. The problems were exacerbated by a fault with the deprecated secure.wikimedia.org server (wikitech-l mailing list), which caused some scripts to fail simply of their own accord and by the kind of dependency problem developers were already expecting (example). Although developers looking at the issue were initially puzzled by the intermittent nature of the main problem, there is now a growing consensus that most of the problems will resolve themselves as various caches get invalidated. Unfortunately, problems with the release were not confined to user scripting; indeed, quite a number of short-term fixes were needed to stop the update crashing servers due to its unexpectedly high memory footprint, whilst bugs relating to merging accounts and the recent changes IRC feed are still outstanding (also wikitech-l: 1, 2, 3)
Nonetheless, the deployment team is still expected to be able to keep to the original deployment timetable, which sees the final Wikimedia wikis upgraded during the early hours of March 2. Indeed, there are significant incentives to make sure that it does: the main Git switchover has already been scheduled to begin on March 3 (see below), making any overrun inherently problematic.
Main Git switchover confirmed for March 3–4
WMF developers confirmed this week that the canonical repository for the core MediaWiki software will be changed from the current Subversion repository to a new Git repository over the course of March 3–4 (wikitech-l mailing list). The long awaited move will therefore immediately follow the deployment of MediaWiki 1.19 to Wikimedia wikis, but precede its full release to external wikis.
The relatively tight schedule will head-off the risk that code review is allowed to get out of hand between the deployment (for which the number of unreviewed revisions was driven down to zero) and the switchover (for which the number of unreviewed revisions needs to be at zero). It also prevents the potential for any overlap between old-style "post-commit" review and new style "pre-commit" review, and hence the possibility of the same code being reviewed twice. Staff took the opportunity this week to explain the reasoning behind the switchover on the Wikimedia blog, and on the wikitech-l mailing list there was a discussion of the elements of the new system most likely to take developers by surprise, including references to several bugs. A separate thread discussed instructions for those who did not develop MediaWiki, but were still reliant on the old repository for keeping their installations of MediaWiki on the bleeding edge.
Extensions running on Wikimedia wikis will be transferred to Git immediately after the core MediaWiki code. Non-WMF extensions in the shared Wikimedia.org SVN repository can either take up the offer of a transfer, or elect to sort out their own hosting arrangements. Developers suggest that extension maintainers are likely to have around 12 months to make the decision before the old repository goes read-only.
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.
- Swift support stutters: Very shortly after the Signpost went to press last week, problems with the transfer of thumbnail functionality to a new, more extensible Swift-based system, came to the fore. Contrary to last week's report that only "minimal disruption" had been caused by the transfer, it transpired that the system was actually significantly slower than expected, delaying some page load times by as much as ten seconds. Fortunately, the problems with the new system could be quickly resolved; at the time of writing, all thumbnails were once again being processed via a Swift-based backend.
- IRC meeting to discuss ResourceLoader: The next MediaWiki Workshop (aimed at both volunteer and staff developers) will focus on the ResourceLoader, and will be held on February 23 at 21:00 UTC in the #wikimedia-dev connect IRC channel. Developer Gregory Varnum, in introducing the project, described it as "an opportunity to learn more about utilizing MediaWiki's ResourceLoader [and] to ask questions about developing MediaWiki extensions" (wikitech-l mailing list). Further development work on the ResourceLoader, which was introduced in MediaWiki 1.17 as a way of speeding up page load times, will go live as part of the MediaWiki 1.19 release.
- Racial slur tweeted by official account: Users following the official @wikimediatech Twitter and Identi.ca accounts were surprised this week to read two "problematic" tweets emanating from the accounts, one of which included a "racial slur" (wikitech-l). A quick investigation traced the source of the tweets to corresponding malicious server admin log entries, which were themselves prompted by the actions of an IRC troll (all log entries are automatically tweeted by the @wikimediatech account without pre-post moderation).
- Adjustments to bot approval process: Several discussions were started on the talk page of the English Wikipedia's Bot Approvals Group to discuss whether any changes in procedure were required. The debate follows recent suggestions that the group, which is responsible for approving or declining requests to run bots on the grounds of community consensus and quality of implementation, may need to rethink its policy to place greater emphasis on the history of the operator requesting the task.
Discuss this story