Just how bad is the code review backlog?
Code review backlog plotted over time
.png)
Developers were left one step closer to an understanding of the code review outlook this week after the creation of a graph plotting "number changesets awaiting review" over time (wikitech-l mailing list). The chart, which also shows the number of new changesets created on a daily basis, reveals a peak in the number of unreviewed changesets in mid-July, followed by a short drop. The current figure stands at approximately 219 unreviewed changesets.
Apparently little more than a number, non-technically-inclined users may question the relevance of such a statistic. By contrast, many developers – particularly volunteer developers – care greatly about its implication for the time it will take for their code to gain the attention of senior developers. As volunteer Brian Wolff wrote this week in his comprehensive roundup of his Git and Gerrit experience five months on, "[now we're using Gerrit] it requires someone to approve your commit, as opposed to merely someone not finding an issue with it. Thus if nobody cares, your commit could sit in limbo for weeks or even months before anyone approves it ... [the result is] less instant gratification".
Nevertheless, others may wonder if code review has ever really been that big of a problem, given that the situation is apparently always bad, and yet has never seemingly reached crisis point. To do so would be to forget the forced surges of review activity before previous release deadlines that left many major development projects behind schedule. Of course, such surges will no longer be prompted in the same way for MediaWiki 1.20 and beyond: replaced by what is likely to be a perennial concern for review timeliness that will only ease slightly on the back of these figures.
In brief
.png)
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for several weeks.
- Busy week for Lua: Last week's deployment of Lua to test2wiki, combined with this week's deployment to MediaWiki.org (wikitech-l mailing list) conspired to create a buzz around the template programming language that included the "Luafication" of several prominent citation templates. Predictably, widespread excitement was tempered by specific concerns, many of which were referenced in last week's "Technology report"; nevertheless, few if any commentators felt that the scheme ought to be abandoned and the French Wikisource has already put its name forward to be the first user-facing wiki to trial the software. Likewise, this week's poll results suggest that there could eventually be a significant body of Lua-competent editors, on the bigger wikis at least (example code editor). A full introductory video is also available as of this week, being the video of a presentation given by Lua lead Tim Starling at this year's Wikimania conference.
- Google Summer of Code: pencils down please: The Google Summer of Code programme has now officially drawn to a close, with all eight of the nine MediaWiki participants who made it to the halfway point seemingly passing the final evaluation. Each has submitted (or will be submitting) a final wrap-up report; many will also choose to be profiled in the pages of the Signpost. Students now have a fortnight to confirm their award by submitting code samples to Google, before beginning the long, hard road to either an eventual deployment (for those with WMF-suitable projects) or widespread adoption. Late on Monday, serial commentator MZMcBride enquired about which metrics might be used to justify the benefit of MediaWiki's annual participation in the scheme, receiving several responses.
- Planet software upgraded: Planet, the software that powers the language specific subdomains of planet.wikimedia.org, was upgraded this week (wikitech-l mailing list). Wikimedia had previously been using an unmaintained version of the software, which collates entries from multiple blogs into a single feed; it is now running Venus, a maintained fork of the original project available from the Debian package repository. The list of feeds included in the English-language has also been trimmed and revised to reduce the number of errors and warnings generated during the site's daily update cycle.
- Appreciation thread: In overt contrast to last week's negativity on the developer mailing lists, WMF Engineering Community Manager Sumana Harihareswara began a thread entirely devoted to spreading "appreciation" for other developers' effort (wikitech-l). One of the most popular threads of the week, the topic has provoked a dozen posts naming some 25 technical contributors, including some seemingly deliberately targeted at smoothing over some of the previous controversies. Harihareswara also posted a directory of mailing lists developers may have been unaware of.
- Wikimedia, thumbnails and running out of space: Software developer Ariel Glenn this week blogged about Wikimedia's uncertain stance on thumbnail caching and the implications of this for its longterm hardware demand. "How do we keep our pile of scaled media from expanding at crazy rates? ... Should we limit thumb generation to specific sizes only?" asks Glenn, suggesting a future debate on the topic, which has been influenced by the introduction of new distributed storage system Swift after initial difficulties.
- Six bots approved: Six BRFAs were recently approved for use on the English Wikipedia:
- AnomieBOT's sixty-sixth BRfA, performing clerking tasks at WP:DRV;
- Legobot's seventeenth, fifteenth and eighteenth BRfAs, creating un-punctuated redirects for SCOTUS cases, being a replacement for HBC Archive Indexerbot, and adding |oldid= to {{GA}} when missing;
- SuggestBot's seventh and sixth BRfAs, automatically posting article suggestions upon user request, and updating Wikipedia:Community portal/Opentask regularly;
- At the time of writing, twelve BRFAs are active. As always, community input is encouraged.
Discuss this story
Programming in Lua Chapter 1, Roberto Ierusalimschy, 2004