After the attempted deployments of MediaWiki 1.17 on 8 February 2011, which were quickly reverted on performance grounds (cf. Signpost coverage), the latest edition was deployed once more to Wikimedia sites on February 16. Although a number of relatively significant problems soon appeared, these were regarded as fixable without the need for a retreat to 1.16 (Wikimedia Techblog). There was only a partial recurrence of the load spikes seen with the previous attempts at deployment.
The anecdotal evidence coming from users is that page loading times have indeed been reduced by the new ResourceLoader as hoped. However, many of the issues wikis are now facing were also related to this change: as expected, it broke a number of JavaScript gadgets, including popular scripts such as Twinkle. Although these issues were soon fixed, users were also riled by a bug with the Vector-style edit toolbar when it was re-enabled for editors who had previously tried to turn it off. On this issue, developer Roan Kattouw said that he "apologized for messing up" and explained that the temporary loss of this preference setting was the lesser of two evils. "There are about 4,200 affected users on English Wikipedia, if memory serves," he added (Technical Village Pump).
Other issues were equally temporary. For example, the new stricter SVG parser refused to accept a number of images it had previously allowed, resulting in a loss of thumbnails. Some were soon fixed with a change to the parser (being incorrectly failed); others still need to be fixed manually as they have invalid syntax which results in discrepancies between web browsers, and, in the worst case, security holes. A change in the color of the "New messages" box from orange to blue (cf. Signpost coverage), was soon reverted locally on the English Wikipedia and several other wikis; the change, which was supposed to make the box visually more similar to the Vector skin, may still be reverted globally.
Developer Rob Lanphier explained where the development team was going to go from here:
| “ | We still have some deployment work left to do... we also want to reintroduce the category [pagination] improvements that Aryeh Gregor made last summer,... plan to update ArticleFeedback now that we’re on the newer codebase, and we’ll probably also update some other extensions, too. | ” |
With the deployment to WMF wikis of MediaWiki 1.17, developer attentions have begun to turn towards the strategy for MediaWiki 1.18. Mark Hershberger, developer and interim bugmeister (cf. Signpost coverage), outlined his views on where MediaWiki development should go from here (Wikitech-l mailing list):
| “ | The solution I'm proposing is that we branch 1.18 immediately after the release of the 1.17 tarball [the release to non-WMF wikis expected in the next couple of weeks]. Revisions on the trunk could be [proposed to be] merged to the 1.18 branch. Or, to make merging into 1.18 less of a chore for a single person, we could enable those doing code review to merge code they've reviewed into the 1.18 branch. In this way, we achieve Roan's (and my) goal of continuous integration [reviewing and deploying code very rapidly, rather than waiting for large set-piece deployments]. | ” |
The issue has been a hot topic in recent months (cf. Signpost coverage from October 2010: 1, 2) and this week proved no exception. Discussions included a debate of the merits of Subversion as the best version control software to be used, and whether a Mozilla-style system (where all developers submit patches, rather than adding their changes to the global codebase immediately) might be a better step. Developer Roan Kattouw expanded on Mark Hershberger's more modest proposal:
| “ | If we want to move to continuous integration (and I think the consensus is we do, considering the mess we've made for ourselves by deploying 9 months worth of commits and not knowing which of the ~15,000 new revisions killed the cluster the other day), our first step should be to get closer to continuous integration, i.e. bring deployment closer to trunk [the bleeding-edge codebase]. By the time we deploy 1.17, trunk will already be more than two months ahead... Stabilizing and deploying 1.18wmf1 should take considerably less time and allow us to get much closer to a continuous integration model. | ” |
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.
Early on Saturday, 19 February 2011, bugmeister Mark Hershberger posted a list on wikitech-l of critical bugs to work on over the weekend and fix before a MediaWiki 1.17 tarball is released.
P.Copp reported bug #27302, a ResourceLoader bug that attached a timestamp to site JS and CSS (e.g. MediaWiki:Common.js), even if these were empty, and attached timestamps to user JS and CSS, thus bypassing the caches, even if a user is logged out and does not have user JS or CSS. Developer Roan Kattouw fixed (r82219 and r82468) the bug, and with the fix, cut load to the 4 Apache servers serving ResourceLoader in half. [1]
Over the weekend, the following other bugs were fixed:
![[1]](http://file.status.net/i/identica/catrope-20110216T150241-xmvxh2t.png){kind=link}
Discuss this story