The process of reviewing all those revisions set to be part of the latest version of MediaWiki, 1.18, is drawing to a close, at least numerically. Data published this week show that the number of unchecked and potentially problematic revisions has fallen from a high of 1500 to under 100. Given that these are likely to be large, difficult to check revisions, a new page has been created on MediaWiki.org to list those that still need to be checked for errors. As of time of writing, some 90 revisions are listed, divided into several categories based on priority.
Despite this prioritisation of reviewing, developer Robert Lanphier emphasised in a post to the wikitech-l mailing list that zero remained the target, writing that "we want to get through everything anyway... we're all looking forward to seeing this list shrink to zero". After the code review backlog is substantially reduced, 1.18 will undergo a period of being tested for bugs, before being pushed live to Wikimedia wikis. It is unlikely to be made available to external sites in packaged form until it has demonstrated its stability on Wikimedia wikis.
Subversion (full name Apache Subversion but usually shortened to simply "SVN") is the software that handles the collaborative development of MediaWiki. By and large, it handles this in much the same way as contributing to a wiki; developers grab copies of the files they want to edit from a central repository, change them, and then "commit" their changes back to the central repository. (Developers can also get edit conflicts; Subversion provides only basic protection against them and this is one of the reasons why a move to software seen as more conflict friendly, such as Git, has been suggested in the past—for context, see previous Signpost coverage: 1, 2.)
A simple Subversion workflow where each number is one "commit" (note that Wikimedia does not currently use tags, only branches)
The nature of Subversion ultimately defines the current development workflow for MediaWiki in many key respects. The majority of coding is done on local copies of the bleeding edge "trunk" code, but Subversion also allows for a process known as "branching", where elements within the repository are duplicated, allowing for a developer to choose to which copy his or her changes are applied. As a general rule, new features will continue to be added to trunk, whilst bug fixes will end up in both branch and trunk code. This process allows for the branch to "bake": that is, to become free of bugs by maintaining a fixed feature set. These branches, when stable, then form MediaWiki releases.
As of time of writing, 1.18 is currently baking; on 18 July it was re-branched from trunk, whilst a branch made some three months was renamed and put on hold. 1.18 will therefore take advantage of the ongoing improvements in the stability of trunk code; if 1.19 is still to be branched soon, it would therefore be more of a stability rather than a feature-oriented release. A second strategy would be to delay 1.19 to allow for new features to be incorporated before release.
Wikimedia Commons and other projects have been hit by a series of problems relating to the caching of thumbnails. Filed as bug #28613, the problems have left thumbnails appearing out of date, even those provided on file description pages themselves.
The Wikimedia Foundation blog carried a post to coincide with the start of the rollout of the ArticleFeedback extension to all articles on the English Wikipedia, as noted by the Signpost last week. It looked at some early findings and recent developments in the available functions.
WMF contractor Sumana Harihareswara proposed installing the "Splinter" Bugzilla extension to allow proposed patches to be reviewed more easily (wikitech-l mailing list). The Volunteer Development Coordinator also posted about the talks she had attended during her WMF-funded trip to the Open Source Bridge conference held in Oregon, United States. A more comprehensive list was given on her blog.
With the resolution of bug #29938, the MediaWiki API will now return the correct user groups for a given user, rather than assuming they are, for example, autoconfirmed.
Lead Software Architect Brion Vibber blogged about some early stage development work he is doing on a new MediaWiki parser and its technical demands.
The MoodBar extension will be trialled with new users this week. It will allow them to submit short statements whenever Wikipedia makes them "Happy" or "Sad", explaining what caused their change in mood. Its current prototype is similar to that of a button provided to testers of Mozilla Firefox, but expected to develop over time (more software deployments).
The Foundation's Annual Plan included a commitment to increase read-uptimefrom 99.8% to 99.85% within the next year. Both figures are substantially lower than the informal targets referred to in the past by outgoing CTO Danese Cooper, but the change nonetheless represents 25% less downtime for readers.