The Signpost
← Back to Contents
View Latest Issue


Technology report

1.19 deployment stress, Meta debates whether to enforce SUL

Contribute  —  
Share this
By Jarry1250

Only Wikipedias still to be upgraded to 1.19

Though the deployment of MediaWiki 1.19 was problematic, it is now running on all Wikimedia wikis except Wikipedias.

After a long and difficult week for developers, all Wikimedia wikis except Wikipedias are now running MediaWiki 1.19. Unfortunately, every deployment uncovered new problems that required fixing. Some deployments had to be reversed just minutes after they went live.

Wikimedia Commons was the highest-profile wiki to switch over in the past seven days, but required three deployment attempts (wikitech-l mailing list). The first two attempts, both on February 21, encountered such severe problems in performance, thumbnailing and JavaScript that developers reverted to the prior version. On February 22, the third deployment attempt was successful, despite several reported problems reported on the Commons village pump. Fortunately, these did not require a third reversion to 1.18; instead, developers pushed through a series of bug fixes that allowed the wiki function well enough, although not perfectly.

The hustle and bustle of the 1.19 deployment did not end at Commons. Spanning February 23–24, the Wikinews wikis were switched over to the new version, then switched back, then switched over again. Wikisources suffered a similar fate. Finally, all other non-Wikipedia wikis (Wikiquotes, Wiktionaries, Wikiversities, and the others) installed the version new later on February 24.

The deployment of 1.19 is likely to yield many useful lessons. Given the proximity of the deployment to fundamental changes in the MediaWiki release cycle, these lessons are likely to have an immediate impact. Most strikingly, several new and important bugs came to light at every turn over the past week, a stress no one will want to repeat during the more rapid future deployments planned for later in the year. Nor is the stressful period over yet: at the time of writing, 14 bug reports and one tracking bug are set to require fixing before the final deployment to the English Wikipedia, currently scheduled to finish in the early hours of March 1[nb 1] The list includes problems with the Wikimedia Commons Upload Wizard, Oversight-related issues, and a serious bug in the ProofreadPage functionality upon which a number of Wikisources depend. Given the importance of the March 1[nb 1] date, it will be another intense week for developers.

Corrections

  1. ^ a b An earlier version of this article incorrectly carried the date of March 2, repeating an error made on the MediaWiki roadmap article for the deployments.

SUL convergence: yea or nay?

SUL, also known by its extension name of "CentralAuth", permits users to "call dibs" on their chosen username on all wikis simultaneously.

A discussion was started this week on Meta regarding the current implementation of the SUL ("single user login") system used to prevent cross-wiki confusion or imitation. The system, in use across Wikimedia wikis and also known by its extension name of "CentralAuth", permits users to "call dibs" on their chosen username on all wikis simultaneously rather than just the wiki(s) where they officially register. The duplicate accounts themselves are only registered if and when the user visits the foreign wiki whilst logged in.

SUL itself has been around since late 2006 but despite this, username "conflicts" – where different users have registered the same username on different projects – still persist. To ease the problem, in 2009 the SUL configuration was changed so that any username registration automatically detected as conflict-free was automatically made a globally unified login. However, usernames that had been registered already were not retrospectively made global even if they were conflict-free at the time—a decision the proposal on Meta seeks to overturn.

One potential problem in the pipeline is that no system for global renames has yet been devised, making it tricky for users who do visit numerous other wikis to change their username whilst preserving their contribution history. Proposers say that despite the downsides, the move is justified because of its potential to spur the development of global watchlists and other much-requested technical improvements of a global nature. The proposal, which had garnered a small but significant amount of support as the Signpost went to print, has not received much comment on technical feasibility thus far.

In brief

A mockup from the Wikimedia Android App project, showing the Save Article facility; version 1.1, of which a second beta was release this week, includes a "Clear saved articles" button among its new features

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.

← Previous "Technology report"
Next "Technology report" →
S
In this issue
27 February 2012 (all comments)
  • News and notes
  • Recent research
  • Discussion report
  • WikiProject report
  • Featured content
  • Arbitration report
  • Technology report
    • + Add a comment

    Discuss this story

    These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.
    • Another excellent report, and explains those episodes of problems with thumbnails I experienced recently. Sleep deprivation doesn't seem to impair your writing! MathewTownsend (talk) 01:28, 27 February 2012 (UTC)[reply]
    • Hmm, we should really make some sort of global user rename. Requesting on each wiki individually is really not feasible for people who contribute to many wikis. As for technical feasability (of global renaming) - rename ops are already fairly expensive, but they're done with job queue. I can't imagine it would be inherently unfeasible to add something to the job queue to any wiki edited (that is at most something like 600 wikis, probably significantly less in most cases). Bawolff (talk) 02:36, 28 February 2012 (UTC)[reply]
    • I should probably clarify. I wrote the Short URL tool as part of Redwerks rather than in my spare time like the other stuff I've done. The authorship should probably be Redwerks or something like "Redwerks' developer Daniel Friesen" rather than credited directly to me. Dantman (talk) 05:58, 28 February 2012 (UTC)[reply]
    • I've edited the report to correct the enwiki deployment date: it's February 29th (starting around 23:00 UTC), not March 2nd. I asked RobLa in person (his desk is next to mine) and he confirmed this. --Catrope (talk) 18:12, 28 February 2012 (UTC)[reply]
    • Interesting read, as always. Building on what Bawolff said, having a SUL would be fantastic for facilitating global renames. I'm currently in the process of changing my usernames across my ancient accounts. Doing them in the right order, remembering which links to "prove" I'm the owner on different sites, waiting for them to be done so I can finally unify them... necessary but confusing! As Bawolff said, an SUL wouldn't imply a unified job queue (right?), and would allow the transition to be staggered when resources permit. I suppose though this could lead to confusion when users notice some sites change when others haven't yet... though nothing like the current level of difficulty with changing names! In any event, reading up on this issue and being in the thick of it right now (so to speak) has given me a greater appreciation for what the Wikimedia team are facing. --RubenSchade (talk) 13:22, 29 February 2012 (UTC)[reply]
    The Signpost is looking for new talent.

















    Wikipedia:Wikipedia Signpost/2012-02-27/Technology_report