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:
| “ | UploadWizard is a step-by-step, multi-file uploader extension for MediaWiki that was developed as part of the Multimedia Usability Project. We launched a beta version in November 2010, and have been working on getting it to release quality ever since... We've focused on achieving a pleasant interface, that works on all browsers, that orients users to Commons' mission and helps them make good contributions...
By the way, some people find the UploadWizard's design a bit surprising — you can upload files before you set a license or describe them, which sounds a bit dangerous (but not the way we've done it)... And what else is left to do? Well, after this is deployed, we're going to be watching things very closely to see how this affects Commons. Our goal is to increase the number of contributions, and the pool of contributors — without any downgrade in quality or burdening the community with spam. We have some plans about how to determine that, but we could always use more help there. |
” |
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
titleattribute (commonly displayed as a tooltip by browsers) will no longer be set, in order to comply with current accessibility guidelines.
Discuss this story