January sees prototype new geodata API; but February looks to be a testing time for top developers
January engineering report published
The Wikimedia Foundation's engineering report for January 2012 was published last week on the Wikimedia Techblog and on the MediaWiki wiki, giving an overview of all Foundation-sponsored technical operations in that month. The projects and events picked out by the report writers (the San Francisco Hackathon, SOPA blackout, release of an official Wikimedia Android app, and creation of extra testing facilities ahead of 1.19's deployment) have all been covered in the previous issues of The Signpost; however, the report did contain several items of note that were not.
For example, the report describes how developers Trevor Parscal and Roan Kattouw recently visited Ballarat, Australia to attend the linux.conf.au conference, where they presented a talk about the Wikimedia Resource Loader entitled Low-hanging Fruit vs. Micro-optimization, Creative Techniques for Loading Web Pages Faster. It also includes a list of 11 open engineering-related positions at the Foundation, as well as confirmation of the changes in personnel over the month; news of the successful upgrade of Wikimedia's mail servers (likely to allow all users to enjoy email notifications for watchlist changes if they so wish); and expansion in the number of projects running on Wikimedia Labs; the slower but still good progress in expanding the range of functionality included in the new parser (and hence eventually destined for support in the new Visual Editor); and the creation of a beta geo-coordinate API module that will allow, for example, proximity searches when fully deployed and integrated.
Testing time ahead for top developers
At the time of writing, https://test2.wikipedia.org is set to soon be updated to run MediaWiki 1.19. This will yield the closest approximation yet of how the software is likely to fare when deployed to front-line wikis, as it is scheduled to in the coming weeks (see also a detailed recent blog post describing how best to help test the software before its release). 1.19 had been formally branched on Wednesday, clearly defining which features have and have not made it into the release: from now on, only bug fixes will be accepted into the branch.
Unfortunately for the head developers managing the release process, the hard part is still to come. From here on in, they will be fighting not only to get 1.19 out on time and on spec, but to ensure the swift and satisfactory switchover of the core MediaWiki repository from Subversion (SVN) to Git. The former had required a long code "slush" in order to allow developers to review months' worth of unchecked code; the latter demands that in many respects it must continue until Git is cut loose from SVN ( wikitech-l mailing list). Long code slushes are difficult for developers to work with, however, since they block easy collaboration and obstruct development work more generally; indeed, avoiding the need for future code slushes (or indeed full code freezes) is one of the motivating factors behind the switchover. The next few weeks, then, are likely to be tense ones as staff and volunteer developers alike hold back on major development work unrelated to getting 1.19 on time and agree upon the myriad of details necessary to ensure a clean Git switchover, first of core code and later of extensions ( also wikitech-l).
One such detail that received discussion time this week was the code review system to be used under Git (since the current system is highly customised for use with SVN). A system developed at Google and known as Gerrit was generally assumed to be the preferred choice, with some members of the Wikimedia system administration team already using it. This week the prospect was raised of instead switching to the more GUI-friendly Phabricator developed at Facebook; lead developers have decided to postpone a final decision until the summer and to use Gerrit in the meantime (also wikitech-l).
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.
- FOSS, a beginner's guide: Open Advice, subtitled FOSS: What We Wish We Had Known When We Started, was published online this week. Naturally, the collection of essays about Free and open software, which includes contributions for MediaWiki regulars such as Guillaume Paumier and Felipe Ortega, is free to download and open-licensed. Essay topics (of which there are 42) span "from 'Writing patches' to 'Documentation for Novices', to business models, conferences, translation, design, and more". The comprehensive 300-page work is available in PDF, mobile, and print editions ( Wikimedia blog, direct link to accompanying website).
- API formats to be phased out?: After it was discovered that certain API formats would routinely output content deemed (incorrectly) as unsafe by well-known security software, there was a discussion on the wikitech-l mailing list about the possibility of dropping support for a number of output formats entirely. JSON is currently the preferred output format, and the one recommended for new API users.
- Berlin Hackathon dates confirmed: This year's Berlin Hackathon will be held on 1–3 June, it was confirmed this week ( wikitech-l mailing list). The hackathon, which is sponsored by Wikimedia Deutschland and now in its fourth year, is expected to have well in excess of 100 attendees, and will cover "user scripts, gadgets, API use, Toolserver, Wikimedia Labs, mobile, structured data, templates" and other topics.
- Prompt for edit summary? But there's one there already: With the resolution of bug # 17416, the inbuilt "Prompt for edit summary" preference will no longer prompt for a new summary if the user has simply accepted the preloaded edit summary.
- Thumb file backend system migrated: As discussed in last week's "Technology Report", this week saw significant migration of Wikimedia's file backend. All thumbnail images are now being served by Swift, the new, more scalable system designed to increase redundancy and hence avoid future glitches from affecting end users; the images themselves are set to follow later in the year, according to a post on the Wikimedia blog. As predicted, there was minimal disruption during the switchover period.
- Translation memory upgrade: Translatewiki.net founder Niklas Laxström described this week on his blog his recent efforts to improve translatewiki.net's translation memory capabilities. Such a memory allows translations to be pre-filled based on similar past translations, saving translators increasing amounts of time and hence allowing them to translate more, quicker. In other localisation-related news, fellow team member Gerard Meijssen used a blog post to note the open question of how the translation framework might be adapted to work better in the months leading up to Lua-integration (see previous Signpost article for context).
- The role of Volunteer Development Co-ordinator: Sumana Harihareswara, who currently works as the WMF's Volunteer Development Co-ordinator and whose name appears regularly in editions of the "Technology Report", blogged this week about what that role had entailed, through the lens of events since 1 February. The list included at least 285 work-related emails sent as part of her work to "nurture the software community that supports the Wikimedia movement".
Discuss this story