Jump to content

Wikipedia:Wikipedia Signpost/2011-03-28/Technology report

From Wikipedia, the free encyclopedia
Technology report

UploadWizard release; code review – should MediaWiki move to Git?; brief news

Upload Wizard release expected shortly

This week, Neil Kandalgaonkar, a developer working with the WMF, blogged about developments on a new UploadWizard the Foundation was working on. He announced that the wizard, aimed at easing new users into uploading to Wikimedia Commons, was nearing a stable release (Wikimedia Techblog). As well as noting that a deployment to Wikimedia Commons is expected "by the end of this month", he explained the project:


Why isn't code being reviewed as quickly as it's being written?

A long debate formed this week on the wikitech-l mailing list about the issue of code review. The fundamental problem will be familiar to regular Signpost readers: that the review process just can't keep up with the volume of new code being written by developers day in, day out. Readers may also be familiar with the recurrent debate about which Version Control System MediaWiki developers should be using: the incumbent (Subversion, SVN), or an alternative (such as Git, or a similar system known as Mercurial).

This week's debate combined the two, as the question was asked, "is there still interest in [preparing for a move to Git]". The debate started with direct questions about the practicalities of transferring to a new system, the benefits, and how it may change the development cycle. Critics highlighted the difficulty of submitting localisation updates to the multiple code repository system preferred by Git users, though Git's capability to handle complex updates was defended by advocates on the grounds that it merely required new automated scripts to be written. The discussion then broadened onto the impact this would have on code review times, and the process of code review.

A number of WMF developers hold that a move to Git or similar is in the best long term interests of MediaWiki post-1.17. A number of suggestions came from various developers: go entirely to Git with a separate repository for each of MediaWiki's hundreds of extensions, to maintain one SVN repository and one Git repository for "core" code (also known as "phase3"), and to do the same but have them both as Git repositories. The contra position was taken by Mark Hershberger, who suggested that rather than rely on the arrival of "the mythical GIT", developers should ask "what can we do to improve code review now?" He suggested reverting unreviewed code after a period of seven days, with effect from next week. Roan Kattouw, who supports a move to Git, supplemented the proposal with improvements to "reviewer allocation, discipline and assignment" before implementation. Simetrical also highlighted concerns that after the 1.17 release, paid developers would be moved off code review where they were desperately needed.

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.

  • The SSL certificate for HTTPS support on secure.wikimedia.org (Singer) briefly registered as "expired" before it was renewed by the Foundation (wikitech-l mailing list).
  • Gerard Meijssen blogged about his "ten suggestions", a collection of what he sees as "the top MediaWiki challenges", and about MediaWiki's PDF support.
  • The file blacklist, which prevents uploads with names such as DSCF001.jpg, was restored to functionality (bug #27470).
  • Mark Hershberger posted a list of "sprint" bugs that need to be fixed before the 1.17 tarball release (wikitech-l mailing list). Several have since been fixed.
  • Developer Tim Starling suggested changing the focus of MediaWiki's PHP optimisation strategy from just the Zend compiler to both that and Facebook's new HipHop compiler (wikitech-l mailing list).
  • Bug #542, from September 2004, was finally closed. The successful resolution means that for some simple links, the title attribute (commonly displayed as a tooltip by browsers) will no longer be set, in order to comply with current accessibility guidelines.