Wrangling over the optimal release strategy for the MediaWiki software that powers both Wikimedia wikis and other websites continued this week on the wikitech-l mailing list. It follows the publication of a Foundation-led "post-mortem" of the 1.17 release, which discussed what was done well and what could use improvement at a time when 1.18 is looming. The team were generally happy with the finished product, but identified weaknesses in the early-stage release process (particularly under-documentation) that made it difficult to distribute among multiple staff members.
The main point of contention, however, is the desirable number of releases per year: the report noted that "The range of opinion seems to be anywhere from 'multiple times a day' to 'every six months'", whilst a follow-up post by volunteer MZMcBride concluded that there was a fundamental difference between the view of the release manager (Tim Starling), who argues for slower release, and "Brion, Neil, Chad, Roan, and in some ways Erik, among others" who want quicker releases. As a consequence, he argued, Tim achieved his own goals but not necessarily those of the broader community. More broadly, the accompanying thread saw the first significant discussion about actively trying to break the current system of similar WMF and non-WMF ("tarball") release schedules. Developer Roan Kattouw summarised his own view, namely that "3 [tarball] releases per year is fine. However, I think we should deploy to WMF sites much more often than that". This got agreement from Bryan Tong Minh and implicit support from MZMcBride.
As a result of the process issues identified, the WMF tech team held meetings on 7 and 8 July to discuss "the code review, deployment and release management process" – including the timing issues above – and to answer questions such as"how do we dissipate key skills more widely among both staff and volunteers" and "how/when can we split "big hairy projects" with integration issues into more manageable chunks" (also wikitech-l). The draft results of the meeting, published on mediawiki.org, suggest that a move to more rapid deployment is likely to carry the day, as are an effort to reduce the stigma attached to being reverted and further pushes towards a "continuous integration" model.
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.
How you can help
Register at Bugzilla
To comment on bugs, you need to be registered at Bugzilla. This is a great first step for users anxious to help direct software developments (Note that Bugzilla exposes your email address to other users.)
Bugmeister Mark Hershberger called for a triage of bugs attached to old versions. Given that the task only required attempting to reproduce the bugs, he argued that it was ideal of non-coders anxious to help (wikitech-l mailing list). A second triage aimed to identify "easy" bugs perfect for 'wannabe' developers (also wikitech-l).
Users reported problems with using the secure server. Although almost certainly related to changes made to the configuration of the secure (HTTPS) servers, the problem is yet to be authoritatively declared fixed at time of writing.
The Romanian Wikipedia has become the latest to take up for-profit company Linterweb's offer to archive its links (Linterweb blog). Other Wikipedias, such as the English Wikipedia, have traditionally sought to avoid reliance on advertising-supported Linterweb, instead favouring sites such as WebCite with mixed success.