WMF works on its release strategy; secure server problems; brief news
Debate over WMF release strategy continues
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.
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.
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.
- An error that impaired the display of those interface messages shown by JavaScript in some web browsers was fixed (bug #29726).
- The JSMin+ library will now be included with MediaWiki. Its JavaScript parser, the only part to be utilised initially, will mean that bad JavaScript will now give the correct line numbers for errors for the first time since the ResourceLoader was deployed in February.
- 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.
- In light of recent improvements to the parallel system of 'unit tests' (see previous Signpost coverage), there were discussions on the wikitech-l mailing list this week about whether support for the more heavy duty Selenium test suite needed to be retained ("Do we need Selenium for anything anymore?", spun-off from "Selenium IDE test for regressing bug"). In separate news, Foundation contractor Sumana Harihareswara opened an RfC on the future of unit tests.
- More than two years after Revision Deletion was enabled, the ability to apply traditional oversight measures to malicious edits was withdrawn from oversighters on the English Wikipedia (bug #18511).
- On the English Wikipedia, this week saw the approval of a new ClerkBot to help with Arbitration Committee administration and a bot to remove stale {{In use}} templates (JL-Bot 6). Meanwhile, BRFAs are currently open for a number of tasks, including a replacement for WebCiteBOT.
- With the resolution of bug #22689, registered users of Wikimedia Commons will be able to see hidden categories by default.
Discuss this story
The secure issue was due to a single apache server that was reinstalled, and repooled, but was not configured correctly due to changes in puppet that weren't tested for installs. I fixed both problems. There should be no more secure issues currently.Ryan lane (talk) 00:47, 12 July 2011 (UTC)[reply]
Contractor, not employee
Thanks for your coverage! Just FYI, I'm a Foundation contractor, not an employee. Sumanah (talk) 16:29, 12 July 2011 (UTC)[reply]