Wikitech-l October 2011

wikitech-l@lists.wikimedia.org

117 participants
108 discussions

Please review: MediaWiki architecture document
by Guillaume Paumier 28 Oct '11

28 Oct '11

Hi, As you may know from previous postings to this list and the Wikimedia Blog, I've been working on a document presenting MediaWiki's architecture. The document will be integrated as a chapter in the second volume of the "Architecture of open-source applications" book. The reason the Wikimedia Foundation agreed to do this, besides the book, was because we thought that such a document would also prove useful for new developers who want to familiarize themselves with how MediaWiki works. See [1] for more context. I just finished most of the write-up, based on the input provided by developers, on the documentation on mw.o, on the doxygen doc, and on deep dives into the code. We'll submit the final draft to the book's editors in about a week, but before that I'd like to ask you guys to review the document. Mostly for accuracy (we don't want to publish something that contains factual errors), but other comments are encouraged as well. Please try to centralize the feedback on the document's talk page to avoid duplication between the mailing list and the talk page. You don't have to review everything; if you want to focus on a specific section, that's fine, and I'll be grateful for any help that you provide. Also, if you find the document useful, please say so on the talk page; it's really difficult to assess the impact of this kind of work, so any feedback will help us determine if we should attempt similar endeavors in the future. The document is at: https://www.mediawiki.org/wiki/MediaWiki_architecture_document/text ; be bold and feel free to edit the page directly, unless the changes are likely to be very disruptive. Many thanks in advance for your help; I'm available to answer any question on- or offlist. [1] https://www.mediawiki.org/wiki/MediaWiki_architecture_document -- Guillaume Paumier Technical Communications Manager — Wikimedia Foundation http://donate.wikimedia.org

5 6

How du I upload images locally from an extension?
by Leonard Wallentin 28 Oct '11

28 Oct '11

Hello all, sorry if this is a noobish question, but I get strange problems when trying to upload a newly generated image from within an extension. It's seems the title of the calling page gets corrupted getting the name of the uploaded file), and sometimes the resulting image, despite being called File:XXX, end up in the main namespace. At times there are also a lot of UNIQ/QINU-strings in the page. These problems seem to appear both when doing the upload from the job queue, and when uploading at once. I am, by the way, not using any globals like $wgOut. This is the actual upload lines (it inside an Semantic MediaWiki Result Printer class, but I've had the same problems when trying it in an ordinary MediaWiki parser function): $ulUser= User::newFromName($myUserName); $mUpload = new UploadFromUrl(); $mUpload->initializePathInfo ( $filename, $tempdir, false ); $status = $mUpload->getLocalFile()->upload( $tempdir . '/' . $filename, $tempdir, $description, 0, false, false, $ulUser ); if ( $status->isGood() ) { unlink($tempdir . '/' . $filename); return true; } else { ... } I'm not a programmer, so the code is probably quite ugly. I'm not even sure this is the proper way to do a file upload, but it's the only way I found working. Any help would be greatly appreciated (e.g. examples of extensions doing file uploads, making it work)! Best regardsLeo Wallentin Leonard Wallentin leo_wallentin(a)hotmail.com +46 (0)735-933 543http://säsongsmat.nu http://nairobikoll.se/ http://twitter.com/leo_wallentin Skype: leo_wallentin -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.10 (GNU/Linux) mQENBE1JuiUBCADsAnoxo1o3G2Apkjs8NHSfbN4g/H8HbS4XXfjruZ6Afu6PBMJI CoiopKmTzQojjUZEjM2i4QsynU2xX4PmpMloPCOXEWxQg7q6HgHKyBU9NroL+17T WA/30jGTmi2pkuznX1LpYKz0r8oSUsrg9oIeJmSbPRP6bNjwlgaDzarfYjcfEFXu Y0s8KdVT1M8Zw2Sq7QuYPaiT+gfLMN5FaCzCZPdHZu8L1lXszTtFxztiF0hTd2C6 8yAW3DlTqTOSWqQtt10tf8VxeXPGxfqs6Ti8s5MsAsUtg9vw0A7gQC36SmRXel7W l/rYbkESqDKANgIT6ofbIru0ozdy/BxnL2wXABEBAAG0LUxlb25hcmQgV2FsbGVu dGluIDxsZW9fd2FsbGVudGluQGhvdG1haWwuY29tPokBOAQTAQIAIgUCTUm6JQIb AwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQOYTL0NQ4Ju9AwQf+L655KY1W 9Q43IOfZ6hJBwfPjhC4pWppptxe4atsSIo+wh+UHd4Zle59LjMZqCGJrFmhRNk+E DtReKuZT/9aZ6yIoqIf0qgqs2L+NPsFprLlsl284cZZtU7YR9oeOVwAK6l58pWfD 1YQnZEOZDcklvunXI7SpFesB3YbuEnlcU3AJQ9hBJquEuMsGXlcXin/1zid+wEWW lkJz4nqp/EaZ9ITHpSzhftsvknskttLqbbEiXyGjMH+FO99S5Vbn9PZAs3axRCHV MWZqx7DLM6FOTlowklLR4lH0UGawwDwjRICDJQlhcS4fA5ORByXE3zbZ45MleQJK aTYuzxb6IVBzBrkBDQRNSbolAQgAv2RTauQ/aQbpS718FPoxPCdA/GgRXvYQ/dle G7m+p0EBUuu+XlDThyQOrWMBy4UICp2OvChfeb0x7SQ2Xg7ahRkWuKnhGiPKkvoZ qBVrbZ1bKcjA6QXcImelICtSjd3UTtCHcfNttEe5d000GaRJBAzsZseDVebpblLt X1z/n/9nsas+moAdRpiyfSPX1HFW57429GzDUsyCvQfqaPwPCuZa4OBtqxw/ydyn hGh1fBcm4bwOU5nqUt+N/d7GXSpZtYChuNhQZj0uwtvMnXJoKyIEPRIx1xkRJTaC uZTZKqnNU3EGwtYDhAgMQpVzFXXBoSBAfV9Jz9XPHd4RidakEwARAQABiQEfBBgB AgAJBQJNSbolAhsMAAoJEDmEy9DUOCbviRgH/3Tm05nqdsFk531eOLMkCqSoPupM YSId04pE9qgKZCGHvqYYxWuksgDj9BFCm+vMfW+e45bX4nd2bxkZecMCVvAOQrsB yKnk7g4BFI6YxYluCt5ouaRPcB73ztk+08z9j0GvlCo3IAp06neoC/IH1XhUvkts bXBzxQt7zO7Gic54U516Qzsr4iD6MQsBkGoaSKtLtk4v8xFMgDWIl1ODy70qabES 7+5IJn0vnh9DWJqkosofRMcqYoblwvf7orDuSgr76wokaTKCCsNEOt7TTbO8XVyQ r3wzIiopALjOj/2N9kxaHg9MQOfERV6prfZmkxPP69ptlCnJVZL7vwTO/0E= =KIpq -----END PGP PUBLIC KEY BLOCK-----

2 1

Re: [Wikitech-l] MediaWiki 1.18 release plans
by Sam Reed 27 Oct '11

27 Oct '11

I was planning on working on the 1.18 release last week, however most of my time was absorbed with Contest related work, meaning this didn't happen. As of writing this email, there are 27 outstanding revisions tagged as 1.18 [1]. 26 are new, one is fixme. All revisons don't have to be merged to the REL1_18 branch at this point. Any major bugs that have been in fixed (that are applicable in 1.18) should be backported if they haven't been already. Helps limit the number of duplicate bug reports we may get. On the bug front, there are numerous outstanding bugs, not all of these need to be fixed for 1.18 [2][3]. Please feel free to remove them from being tarball blockers The intention is to push a beta out this week (today? maybe.. Certainly by the end of the week) Certainly, if anyone knows of anything that really "needs" to be in the beta, please let me know ASAP. Sam [1] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/1.18 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=28425 - Tarball bugs [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=29876 - WMF Deployment related bugs

2 1

MediaWiki unit testing and non-MySQL databases
by Brion Vibber 27 Oct '11

27 Oct '11

Hey all -- I've got a stack of issues discussed during the last couple months' conferences and hackathons to raise, so there may be a few more manifestos on the way. But don't worry, this one will be short! I had a great chat at the New Orleans hackathon with D J Bauch who's been working on maintaining MediaWiki's MS SQL Server support, and also had a very useful email chat a couple weeks back with Freakalowsky who's put a lot of work into MediaWiki's Oracle support. Long story short: though traditionally MediaWiki developers have put very little work on our own into maintaining non-MySQL compatibility, there's still lots of folks interested in running on them... AND THEY ACTUALLY MOSTLY WORK! At this point I think it's a bit crazy of us to keep on marginalizing that code; some folks running their own instances will need or want or prefer (or be forced by office IT) to run on some "funny" database, and we shouldn't stand in their way. More importantly, keeping things working with multiple DB backends helps us to keep our code cleaner, and reduces our own hard dependencies on a particular product line. There are two main impediments to keeping code working on non-MySQL platforms: * lazy code breakages -- us MySQL-natives accidentally use MySQL-isms that break queries on other platforms * lazy schema updates -- us MySQL-natives add new schema updates into the system but only implement them for MySQL The first could often be helped simply by having automated testing run to make sure that relevant code paths get exercised. Often there's just a function that's used, or lazy use of LIMIT/OFFSET, or GROUP BY in a form that other databases are pickier about. Just flagging them from the testing can often be enough to make it easy to fix. The second is a bit harder, but again testing can help flag that something needs to be updated so it doesn't wait until too late for the next release, or something. I'd like for everybody who's working on MediaWiki on non-MySQL databases to make sure that the phpunit test suite can run on your favorite platform, so we can see about getting them set up in our regular reports on http://integration.mediawiki.org/ci/ Green bars are your friend! :) -- brion

18 33

Visual Editor / parser status update meeting notes 2011-10-26
by Brion Vibber 26 Oct '11

26 Oct '11

I've copied the live etherpad notes from today's Visual Editor / New Parser update meeting onto wikitext-l for those who may be interested: http://lists.wikimedia.org/pipermail/wikitext-l/2011-October/000463.html -- brion

1 0

Announcing Fabrice Florin and Oliver Keyes
by Howie Fung 26 Oct '11

26 Oct '11

Everyone, I am pleased to announce that we have two contractors joining the Technology team. Fabrice Florin will be joining us for the next six months as Product Consultant, leading the development of the next version of the Article Feedback Tool. Oliver Keyes (User: Ironholds on enwp) will be joining us as a community liaison for the next three months. His role is to help ensure that the community input is better incorporated into WMF’s product development process. Fabrice has extensive background in the fields of education and journalism. He is founder and executive director of NewsTrust, a nonprofit social news site devoted to good journalism -- as well as Truthsquad, a network dedicated to fact-checking the political claims made during election campaigns. His previous ventures include: Handtap, a wireless content service for mobile phones; shockwave.com, a web entertainment site at Macromedia; Apple Computer's Multimedia Lab, a new media R&D group; and a variety of other roles in media and technology. Fabrice earned four patents for his interactive TV work at Apple and was recently elected an Ashoka Fellow for his work as social entrepreneur [1]. Read more in his online bio[2]. Oliver has been an editor since 2006 and is both an administrator and an OTRS volunteer on the English Wikipedia. With strong experience in content creation as well as administrative tasks, he has a broad base of knowledge that will undoubtedly be helpful in coordinating community feedback, organizing discussions, and making sure more voices are heard as part of the product development process. As many of you know, the Tech department continues to look for ways to gather input from our experienced editors when designing new features. Oliver’s job will be to act as a conduit between WMF’s development team and members of the community, helping editors make suggestions on feature development and helping ensure that the Foundation incorporates this input. Fabrice may be reached at fflorin at wikimedia dot org, as well as his userpages on the English Wikipedia and Mediawiki ([[User:Fabrice Florin]]). Oliver will be on the projects as [[User:Ironholds]] and [[User:Okeyes (WMF)]]; he can also be contacted directly via http://en.wikipedia.org/wiki/Special:EmailUser/Okeyes_%28WMF%29. We’re very excited to be working with Fabrice and Oliver. Please join me in welcoming them! Howie Fung Senior Product Manager Wikimedia Foundation [1] http://www.ashoka.org/fellow/fabrice-florin [2] http://newstrust.net/about/bio_florin

2 1

Welcome, Antoine Musso! (hashar)
by Rob Lanphier 26 Oct '11

26 Oct '11

Hi everyone, A belated (re-)welcome to Antoine Musso (a.k.a. "hashar" on IRC) as a contractor working on continuous integration (e.g. beefing up our unit tests, improving our Jenkins configuration, figuring out how to integrate TestSwarm, etc). Antoine has been working in our community for quite some time, going by the name "Ashar Voultoiz" on mailing lists, and by "hashar" on IRC. Now that he's working as a contractor for WMF, he's decided to let everyone know the Superman behind the Clark Kent alter ego :) You've probably already seen him be even more active (if that were possible) in SVN and elsewhere since Monday, which is when he officially started. Welcome, Antoine! Rob

5 4

New committers
by Sumana Harihareswara 26 Oct '11

26 Oct '11

* DJ Bauch (djbauch) -- extensions & tools access -- Microsoft SQL Server support * cryptocoryne -- extensions & tools access -- Extension:AutoProxyBlock Welcome! (We are not completely through the commit access queue at the moment, but I hope to get down to zero this week.) -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

1 0

Welcoming Gabriel Wicke
by Alolita Sharma 26 Oct '11

26 Oct '11

Hi All, Please join me in welcoming Gabriel Wicke as a Software Developer in WMF’s Features Engineering team. Gabriel will be working on the Visual Editor - Parser project, one of Wikimedia’s high priority projects this year. He will be working closely with our guru Brion Vibber on extending the parser to support WikiDom interactions with the Visual Editor client being developed by lead engineer Trevor Parscal, Wikia developer Inez Korczyński and front-end developer Neil Kandalgaonkar. As many of you may already know, Gabriel has been member of the Wikipedia community for many years now. He discovered Wikipedia in 2003, when it was still running on two servers. Using his previous experience with Squid caching, he got involved in technical discussions and hacking. In 2004, Gabriel designed and implemented the initial Squid caching layer, and later wrote the MonoBook skin. After completing his Computer Science degree and doing research in transactional distributed systems and Haskell, Gabriel is looking forward to more practical challenges at Wikimedia. Gabriel is an avid sportsman and professional sailor. When he’s not in front of a computer coding away, he is often sailing on his own or with friends. He was a member of the German national team in the Olympic 49er class from 2001-2008, and is now racing an A-Class catamaran. Pretty awesome! Say hello to Gabriel online. He can be found on #mediawiki as gwicke. Welcome back Gabriel! Great to have you on the Wikimedia Features team :-) Alolita -- Alolita Sharma Director, Features Engineering Wikimedia Foundation

9 8

Git migration planning
by Rob Lanphier 25 Oct '11

25 Oct '11

Hi everyone, For a long time, we've been talking about migrating from Subversion to Git. It's time to start getting more serious about it. First: the need to do this. There is pretty broad acceptance that we should move to a distributed version control system (DVCS). Our current Subversion-based version control system has served us well, but we're in need of a more suitable version control system for our development effort. Our community is very distributed, with many parallel efforts and needs to integrate many different feature efforts. While we've developed lots of coping mechanisms, we sure could use a system that's well suited to more fluid branching and merging. There has been resistance to this in the past, and there still may be some resistance. However, I think we've worn everyone down. :) Next: the selection of Git over other DVCSs. Over the past couple of years, other systems have been mentioned (Bzr, Hg), but there hasn't been any evidence (at least on this mailing list) for anything other than mild support for the alternatives. As you might have seen, our Ops folks have already moved to Git[1], and while they're right in the middle of the tough part of the learning curve, they seem to be adjusting just fine. The complaints seem to be of the "I really need to get used to that" variety rather than the "why are we doing this again?" variety. So, given the momentum that Git has, the ample discussion we've had on the subject, and the fact that Ops is already planning to support Git, this seems to be a settled question. So now, the questions shift from "if?" to "when?" and "how?". When? After some amount of arm twisting by Erik and Brion (*hugz*), I've agreed to float a plan that has us making the migration by the end of the year. This is completely contingent on our ability to get 1.19 deployed in a rapid fashion (which, if we can get through the code review queue at our current rate, could be done in November). Until we have a more fleshed out plan, though, "end of the year" purely a guess, and subject to change (partly based on any ensuing conversation after this mail). However, assuming we can clear the technical hurdles, there's not any procedural issues I can see getting in the way of a rapid transition. How? Lots of unsorted pieces. There are still decisions we need to make: * Code review tool: barring unforeseen complications, we're planning to use Gerrit. We need to make sure it'll be a suitable replacement for our existing tool * How do we break up the repository? One big repo? Extensions each get their own? We need to sort all of that out. A draft plan is available here: http://www.mediawiki.org/wiki/Git_conversion Rob [1] ...or so I've read on Slashdot, so it must be true: http://hardware.slashdot.org/story/11/09/21/0531246/wikimedia-foundation-re…

18 26

← Newer
1
2
3
4
5
6
7
...
11
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l October 2011