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.)
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.
Discuss this story
Actually, we are not going to be running a MoodBar trial this week. --Jorm (WMF) (talk) 00:15, 19 July 2011 (UTC)[reply]
- Could you update the wikitech page with a new date, perhaps? - Jarry1250 [Weasel? Discuss.] 00:17, 19 July 2011 (UTC)[reply]
- Would love to, but I'm not the guy who makes for dates, as it were. I can say that development is underway, and that test deployment is probably next week. I cannot speak to when a "real" deployment happens, though, as we have to run user testing. And I'm going on vacation for a week starting Wednesday.--Jorm (WMF) (talk) 04:01, 19 July 2011 (UTC)[reply]
MediaWiki 1.18 was rebranched. --Locos epraix ~ Beastepraix 03:09, 19 July 2011 (UTC)[reply]