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.
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.)
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]