Archive for September, 2009
FlaggedRevs test wiki awaits you!
Apparently due to some miscommunications, a lot of people didn’t realize that the FlaggedRevs labs test wiki has been active and waiting for people to poke at it for a month, since just before Wikimania!
We need interested people to be get up as local administrators to try out the the per-page stabilization settings (accessed via the ‘protect’ tab); by default most pages do not activate FlaggedRevs in the configuration we’re testing for English Wikipedia.
I’ve added a couple quick notes to this affect on the main page.
Update: We’re collecting some folks to be bureaucrats and help set up more test admins so we can get things going quick!
Announce: Brion moving to StatusNet
I’d like to share some exciting news with you all… After four awesome years working for the Wikimedia Foundation full-time, next month I’m going to be starting a new position at StatusNet, leading development on the open-source microblogging system which powers identi.ca and other sites.
I’ve been contributing to StatusNet (formerly Laconica) as a user, bug reporter, and patch submitter since 2008, and I’m really excited at the opportunity to get more involved in the project at this key time as we gear up for a 1.0 release, hosted services, and support offerings.
StatusNet was born in the same free-culture and free-software community that brought me to Wikipedia; many of you probably already know founder Evan Prodromou from his longtime work in the wiki community, launching the awesome Wikitravel and helping out with MediaWiki development on various fronts. The “big idea” driving StatusNet is rebalancing power in the modern social web — pushing data portability and open protocols to protect your autonomy from siloed proprietary services… People need the ability to control their own presence on the web instead of hoping Facebook or Twitter always treat you the way you want.
This does unfortunately mean that I’ll have less time for MediaWiki as I’ll be leaving my position as Wikimedia CTO sooner than originally anticipated, but that doesn’t mean I’m leaving the Wikimedia community or MediaWiki development!
Just as I was in the MediaWiki development community before Wikimedia hired me, you’ll all see me in the same IRC channels and on the same mailing lists… I know this is also a busy time with our fundraiser coming up and lots of cool ongoing developments, so to help ease the transition I’ve worked out a commitment to come into the WMF office one day a week through the end of December to make sure all our tech staff has a chance to pick my brain as we smooth out the code review processes and make sure things are as well documented as I like to think they are. ;)
We’ve got a great tech team here at Wikimedia, and we’ve done so much with so little over the last few years. A lot of really good work is going on now, modernizing both our infrastructure and our user interface… I have every confidence that Wikipedia and friends will continue to thrive!
I’ll start full-time at StatusNet on October 12. My key priorities until then are getting some of our key software rollouts going, supporting the Usability Initiative’s next scheduled update and getting a useful but minimally-disruptive Flagged Revisions configuration going on English Wikipedia. I’m also hoping to make further improvements to our code review process, based on my experience with our recent big updates as well as the git-based workflow we’re using at StatusNet — I’ve got a lot of great ideas for improving the CodeReview extension…
Erik Moeller will be the primary point of contact for WMF tech management issues starting October 12, until the new CTO is hired. I’ll support the hiring process as much as I can, and we’re hoping to have a candidate in the door by the end of the year.
– brion vibber (brion @ wikimedia.org)
CTO, Wikimedia Foundation
San Francisco
Update: Evan’s announce is up on the StatusNet blog.
Theora 1.1 Released
Posted by Michael Dale in wikimedia on September 28th, 2009
Theora 1.1 has been released
Theora 1.1 has been released. This release reflects the efforts of xiph.org developers who over the past year have done incredible work to greatly improve the core free codec video library. This effort has been support by Mozilla Foundation, Red Hat and others. These improvements include:
Chris Blizzard from Mozilla has a detailed blog post about the improvements and what they mean for open video creators, distributors and viewers. Wikimedia foundation makes exclusive use free/open formats and has been a long time supporter of ogg theora and makes use of the free codec in its websites. Wikimedia also helped organize some improvements by administrating a theora improvement grant from Mozilla earlier this year.
Also a new version of ffmpeg2thora has been released using this new codebase making it easy to take advantage of these new features. If you would like to give the new encoder a spin you try it out with the web based firefogg encoding app.
LocalisationUpdate in testing
Ok, we still need to complete automation of update runs for LocalisationUpdate, but it seems to be working!
It’s not the most glamorous of extensions, but you can see here an updated message (”Den här sidan” where the current deployed message file says “Denna sidan har”)!
– brion
Server Donation Entry Period Ending
Just to let folks know, we have had quite a large interest in our donation of some of our decommissioned servers. In fact, I have way too many emails!
So to be fair, rather than just stop today, we will stop accepting submissions for this next Monday, September 28th. That means if you want your proposal/request in the running, you have to have it emailed to servers@wikimedia.org by Midnight GMT this coming Sunday, Sept. 27th.
For ease of reference, here is a copy of the post from the start of this process:
It is that time again. We have approx 35 servers to donate to a good home. These are servers that Wikimedia has used on the projects for 3+ years, so they are out of warranty and just not fast enough for us to keep using on the cluster.
The servers will go out to homes for folks who are willing to pay for the freight. They are as follows:
- Dual CPU 2.5 GHz AMD
- 3-4GB RAM Each
- Most have 80 GB or larger HDD
Disclaimers: The Wikimedia Foundation does not guarantee the operation or use of these servers in any shape or form. They are old, some may have dying fans, bad hdd sectors, and the like. Servers have been wiped of information, and they ran through that, but no promises on function!
If you would like to receive some of these servers for your NONPROFIT use, please email servers@wikimedia.org. Please include in your email how you will be using the servers, and the address they would be shipped to. We will review all requests and try to fairly pick out where they go. (Selection process may be refined, but it also may just include throwing darts at a board to break up ties.)
Additions: Due to request, the servers are indeed located in Tampa, FL USA. Zip code 33602 for shipping purposes. This means that if you are international, shipping this hardware is really not cost effective for you. If you want to be in the running still, and are comfortable with personally handing all customs, duties, export, and tax issues, go ahead and email us.
Correction: Dates were off.
LocalisationUpdate and ProofreadPage second try tomorrow; Collection too
Updates are coming back for LocalisationUpdate and ProofreadPage extensions, which we tested then pulled Tuesday due to performance problems.
Roan’s redone LU to store the message updates in serialized files instead of the database, which we can sync locally to web servers and should perform much better; I’ll also do a more gradual test rollout so we can scale it back more gracefully if we have problems again.
ThomasV has fixed up some bad queries in ProofreadPage, and it should be ready to go again; the updated version has much more advanced index support and looks pretty spiffy. :)
And if we’ve got time between other things, I’ll roll out the updated Collection as well — this makes big improvements to the UI for building a multi-page book, and leaves the sidebar much less cluttered when you’re not using it.
– brion
Commonist, CommonsHelper fixed
I’ve put in a fix for uploader tools and bots that have been broken since the last update — these bot tools didn’t expect the upload form to change, so they don’t pass in new required fields such as the edit token which was added to the form in the latest update.
Since the edit token isn’t actually required for web uploads (it’s a protection against a class of attacks which, as it happens, can’t forge file uploads) I’ve relaxed the check. I’ve confirmed that it fixes Commonist and have a report that CommonsHelper is also fixed.
Most other bots and tools that were affected are probably also fixed; please test them and let us know if anything’s still broken!
LocalisationUpdate deployment delayed
Problem #1 — causes huge increase in CPU load on web servers
Problem #2 — completely kills THE ENTIRE SITE when you DISABLE it because serialized LUDependency objects in the message cache can’t be reinstantiated.
Sigh… Why can’t life be easy :)
Update 2009-09-23 16:30: Roan is starting work on replacing the database storage layer with a flat-file which should be more efficient for our use case.
Feature deployment updates
Quick note for those who have been asking — we’re starting to maintain a list of feature & extension deployments that we’re rolling out in the very near future and their status on the Wikitech wiki.
Note that some things like the English Wikipedia FlaggedRevs deployment aren’t on there yet; we’ll start prepping something for these in the next round in a couple weeks.
– brion
Help us make Commons work better
It’s come to my attention that Commons has had some more problems than we saw on the other wikis… I want to make sure we get that cleaned up!
Andrew has just deployed some more fixes which should eliminate the ‘file already exists on Commons’ bug. It would be a huge help if folks who’ve been reporting problems can go through the lists on the Village Pump and collect just the problems that are still current:
- Uploads via Commonist — fixed or do we still have problems?
- (Who’s the best person to contact about debugging or developing fixes for Commonist?)
- Missing description page immediately after edit — is this still happening?
- Anything else?
Please add info about confirmed problems or fixes at the Commons Village Pump. Thanks to everybody — your feedback is important; we need to know which bugs are affecting you guys the most!
– brion
Update 2009-09-22 23:49 UTC: I’ve fixed the problem with Commonist by relaxing the edit token check in the form handler (this is safe for uploads via the web, which can’t be injected in a CSRF attack; we still enforce it for upload-by-URL). This probably fixes most of the other client-side upload tools and bots as well — please test!
File renaming enabled for admins
Renaming of uploaded files has been disabled for the last couple of months pending software updates; as of today it is now re-enabled for admins on all Wikimedia sites.
Local admins can now rename files as well as deleting them; this makes it easier to track history for images and other media that need to be moved to another name.
– brion
Update 00:49 UTC 22 Sep: We’ve tracked down a bug which at least on en.wikipedia would cause the redirected old name to stop working for 24 hours. Now fixed; notes for cause and workaround on enwp Village Pump.
Beta edit toolbar disabled temporarily
Due to compatibility problems on Internet Explorer after yesterday’s code update, I’ve temporarily disabled the Usability Initiative’s beta advanced toolbar. If you’ve had it enabled, you’ll just get the regular old edit toolbar until we re-enable it.
Hopefully we should have this resolved within a day or so, and it’ll be back on for all our happy testers!
– brion
Update Sep 18 14:13 UTC: the bug has been fixed, and the toolbar has been reenabled.
Babaco Preview
Screenshot of Navigable Table of Contents
As brion’s earlier post stated, the new set of usability features (nickname: Babaco)are integrate into the source code but disabled until these features are stable. New features include, navigable table of contents and content generation dialogues for links, tables, search and replace. These features are currently staged on the usability prototype environment, and you are welcome to check them out and encouraged to push them hard to find bugs. :-)
We are also hoping to integrate add-media-wizard created by Michael Dale in Babaco. While API to extend the toolbar is being worked on, media import functionality can be played at the usability sandbox environment. Click the “Edit” tab and click an image gallery icon in the toolbar. You will see a nice media import function there. Feel free to create an article and import image from Commons using this neat feature.
Browser compatibility matrix for Babaco is found here. As always, share your thoughts and experience through the usability wiki. Feedback on Babaco goes this discussion page.
- Naoko
Software updates Wednesday morning
I’ve been spending much of the last few work days tidying up an update to our deployed codebase, which has been several weeks behind development for most components.
I’ll want to start deploying this in the morning (Pacific time), so we’ll have most of the day to poke around and fix up any problems on the sites… it’s gonna be fun!
This’ll primarily bring a lot of under-the-hood improvements, which’ll let us start rolling out other fun things over the coming days/weeks including:
- Daily updates of interface translations (LocalisationUpdate)
- Updated PDF collection/book UI
- major cleanup of maintenance scripts
- foundation work for improved uploading support
- foundation work for new UI stuff (JS2 / add media wizard / cool stuff from Usability team)
For those of you poking at the code, I’ve got the pre-deployment code currently sitting in the wmf-deployment-work branch; this’ll get folded back over wmf-deployment when we’re ready to go.
I believe all custom hacks from the current wmf-deployment branch have been either copied over or generalized and merged via trunk… Note I’ve held back updates on ProofreadPage and OggHandler for the moment, and we won’t deploy the new JS2 code yet until we’ve shaken things down some more.
If there are any *critical* trunk fixes from the last few days (since r55160 trunk branch point) that need to be forward-ported before we start, or any other surprises, let’s make sure we know about it soon. :)
– brion
Update 1:30 UTC Sep 17: Most problems have now been shaken out. Probably a few more minor glitches to go, then we can worry about prepping the fun stuff! :)
Server Donation Time Again!
It is that time again. We have approx 35 servers to donate to a good home. These are servers that Wikimedia has used on the projects for 3+ years, so they are out of warranty and just not fast enough for us to keep using on the cluster.
The servers will go out to homes for folks who are willing to pay for the freight. They are as follows:
- Dual CPU 2.5 GHz AMD
- 3-4GB RAM Each
- Most have 80 GB or larger HDD
Disclaimers: The Wikimedia Foundation does not guarantee the operation or use of these servers in any shape or form. They are old, some may have dying fans, bad hdd sectors, and the like. Servers have been wiped of information, and they ran through that, but no promises on function!
If you would like to receive some of these servers for your NONPROFIT use, please email servers@wikimedia.org. Please include in your email how you will be using the servers, and the address they would be shipped to. We will review all requests and try to fairly pick out where they go. (Selection process may be refined, but it also may just include throwing darts at a board to break up ties.)
Additions: Due to request, the servers are indeed located in Tampa, FL USA. Zip code 33602 for shipping purposes.
Full TIFF Support is Coming!
Today I had the first milestone meeting with the folks of Hallo Welt about the TIFF support they are implementing for MediaWiki. This is one of the projects Wikimedia Germany was offering contracts for a while back. Now we are starting to see the first results, cool!
So, what will full TIFF support give us? Nothing spectacular, but something quite useful. TIFF is an image format widely used by museums and in scientific research. It’s also the de-facto standard used in print/reproduction. It is however rarely seen on the web, and browsers generally are not able to display TIFF images. However, the need to deal with TIFF files has increased lately, as we get more and more media from museums and archives. Especially for the people who work on image restauration, it is important to be able to have the original digital version of the image around – which is usually a TIFF file. So, TIFF uploads had been enabled on Commons a few months ago. But MediWiki can’t render them, and nither can browsers. They can’t be used as images on the wiki.
So, what Hallo Welt is doing now is implementing rendering support for TIFF files – which is not so easy, because TIFF files may contain multiple images or pages, similar to PDF files, or the DjVu files we use to represent scanned books. But the project is coming along pretty well, and it looks like it will bring some small improvements also to the existing support for PDF and DjVu files. We are also experimenting with automatic user interface testing using the Selenium framework. If this works out well, we may well use it for more things on MediaWiki in the future.
The project is scheduled to be completed in November, and I hope we will be testing it on the live sites soon after. So, look out for more pretty pictures!