Wikitech-l August 2009

wikitech-l@lists.wikimedia.org

94 participants
86 discussions

Reliability of rev_id as order maintaining in enwiki
by Aaron L Halfaker 10 Aug '09

10 Aug '09

I'm using data from a snapshot of the English Wikipedia and would like to run a query similar to the following: SELECT * FROM revision WHERE rev_id > some_rev_id; Can I be confident that all revisions returned were saved after some_rev_id? Thanks! -Aaron P.S. I have considered using rev_timestamp and would like to avoid that if it is possible.

4 3

Bugzilla Weekly Report
by reporter＠isidore.wikimedia.org 10 Aug '09

10 Aug '09

MediaWiki Bugzilla Report for August 03, 2009 - August 10, 2009 Status changes this week Bugs NEW : 179 Bugs ASSIGNED : 14 Bugs REOPENED : 31 Bugs RESOLVED : 140 Total bugs still open: 3780 Resolutions for the week: Bugs marked FIXED : 98 Bugs marked REMIND : 0 Bugs marked INVALID : 11 Bugs marked DUPLICATE : 16 Bugs marked WONTFIX : 3 Bugs marked WORKSFORME : 11 Bugs marked LATER : 1 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component server 7 Site requests 7 General/Unknown 6 CodeReview 4 [other] 3 New Bugs Per Product MediaWiki 21 Wikimedia 16 MediaWiki extensions 19 Wikipedia Mobile 7 Mediawiki Testing Environment 1 Top 5 Bug Resolvers rhalsell [AT] wikimedia.org 33 innocentkiller [AT] gmail.com 20 nkomura [AT] gmail.com 17 roan.kattouw [AT] gmail.com 7 agarrett [AT] wikimedia.org 7

1 0

ParseTree generated by the API and tag extension
by Alex Bernier 08 Aug '09

08 Aug '09

Hello, I have what I think is strange behaviour with parser called by the API and tag extensions. Here is the code of a tag extension : function efParserInit() { global $wgParser; $wgParser->setHook( 'foo', 'effooRender' ); $wgParser->setHook( 'bar', 'efbarRender' ); return true; } function effooRender( $input, $args, &$parser ) { $output = $parser->recursiveTagParse( $input ); return "<div class=\"foo\">" . $output . "</div>"; } function efbarRender( $input, $args, &$parser ) { $output = $parser->recursiveTagParse( $input ); return "<div class=\"bar\">" . $output . "</div>"; } I crate a page on my Wiki with the following text : <foo>test1<bar>'''test2'''</bar></foo> When I view the HTML code in my browser, I get : <div class="foo">test1<div class="bar"><b>test2</b></div></div> But when I try : wget "http://mywiki/wiki/api.php?action=query&titles=mypage&prop=revisions&rvprop…", I get the following in the "parsetree" attribute of the "rev" element ": <ext><name>foo</name><attr/><inner>test1&lt;bar&gt;'''test2'''&lt;/bar&gt;</inner><close>&lt;/foo&gt;</close></ext> (sorry for this ugly line...). My problem is here : there is only one "ext" element which correspond to my "foo" tag. I was waiting two "ext" elements : one for "foo" tag and one for "bar" tag. This is just I want. Is this behaviour normal ? A little bit of debug show that the includes/parser/Parser.php, the "extensionSubstitution" function is only called one time when I access my page via the API and three times when I access it via the browser. Is the text parsed not the same in the two cases ? Is it something wrong in my API call ? Regards, Alex

4 5

GSOC project imgserve 0.1 released
by Wu Zhe 08 Aug '09

08 Aug '09

I am glad to announce the first experimental release of imgserve, a universal image daemon for Wikimedia Foundation, it's a Google Summer of Code project mentored by Aryeh Gregor. The intended usage in mediawiki is to migrate all image manipulation work away from Apache servers. The daemon, written in python, currently only supports image rescaling and svg rasterization operations. Instructions/Requests are sent to the daemon as JSON objects over HTTP, which is handled by an simple embedded HTTP server in the daemon. To test the daemon, you should follow the install instructions and have all required package installed on your machine. See install instructions at http://pypi.python.org/pypi/imgserve Source code is hosted at http://github.com/wuzhe/imgserve As a GSOC student, I have learned quite a lot from this project, and am eager to learn more. If you find any bug, or have suggestions, please let me know, thank you. -- Wu Zhe

1 0

FlaggedRevs for Mediawiki.org?
by Chad 07 Aug '09

07 Aug '09

All, I had this idea cross my mind earlier today, but I got so tied up in meetings that I couldn't sit down and write out a proper e-mail until this evening. I was curious as to whether we think FlaggedRevs might be of use to Mediawiki.org, and if so, how exactly would we use it? The idea crossed my mind after the past several days noticing quite a bit of information on Mediawiki.org is either poorly worded, outdated or just plain wrong. Now, MW.org doesn't suffer from most of the issues that are seen on other projects: we're small, we don't really have anything to edit war over, and we don't seem to get (as much :) spam and vandalism. I was curious as to whether we could use FlaggedRevs as a quality control over our documentation. A lot of the docs have been written by people other than developers, and a lot of the docs have never been read by a developer. That being said, using FlaggedRevs we might be able to deliver more solid docs on MW.org by flagging docs at like two levels. One could be like a basic "has been looked over for glaring errors and basic readability" and a second could be "has been thoroughly reviewed and is considered the doc on the given subject." Hopefully we can improve the overall quality of the docs on MW.org. I'm certainly open to other ideas too. -Chad

8 13

Upcoming tech hiring: CTO position split
by Brion Vibber 07 Aug '09

07 Aug '09

I'm very excited to announce some new upcoming hiring for tech... I've also posted this on our tech blog which is mirrored on Planet Wikimedia: http://techblog.wikimedia.org/2009/08/cto-position-split/ -- Back in 2005, Wikimedia brought me on as the Foundation's first paid employee after two years leading MediaWiki development as a volunteer. Naturally as the *only* member of the tech staff, I started at the top: Chief Technology Officer. In the 4 years since, we've gone from one tech employee to a dozen, from 50 servers to 350, from upstart novelty to established web juggernaut. As our operations and our staff have grown over the years, so have my responsibilities. Beefing up our tech staff is in some ways just like adding servers to our data center -- we can get more things done with less task switching, but scaling still has its overhead. With the increase in administrative and organizational duties, I've been less and less able to devote time to the part of the job that's nearest and dearest to me: working with our volunteer developer community and end users -- Wikimedians and other MediaWiki users alike -- who have bugs, patches, features, ideas, complaints, hopes and dreams that need attention. The last thing I want to be is a bottleneck that prevents our users from getting what they need, or our open source developers from being able to participate effectively! Multicore brain upgrades aren't yet available, so to keep us running at top speed I've suggested, and gotten Sue & Erik's blessing on, splitting out the components of my current CTO role into two separate positions: As Senior Software Architect, I... * maintain the MediaWiki development roadmap * give timely feedback and review on feature ideas, patches and commits * ensure that end-users and bug reporters are treated respectfully and that their needs are met * get developers & users involved and talking at local and worldwide events as well as online * represent the "face of the developers" interacting with our user community (both Wikimedians and third-party MediaWiki users) As CTO, I... * set high-level strategic priorities with the rest of WMF * handle administrative management for the Wikimedia Foundation's technical department & internal IT ** budgeting ** vendor relations & purchase approval ** hiring & personnel details * work with the fundraising side of WMF to seek out and make use of potential resources: ** grants for projects we need ** in-kind donations of infrastructure ** sharing development work with like-minded orgs * ensure that the operations team has what they need to address current and predictable future site needs * ensure that the developers have what they need and are coding smoothly * plan and implement internship programs and volunteer dev events both on-site and elsewhere I'll continue to act in both roles until we've found a satisfactory candidate to fill the CTO position (full job description will go up soon), at which point I'll be freed up to concentrate on being a full-time Senior Software Architect. (Yes, I'll review your patch!) I will of course continue to work closely with our eventual CTO... the idea is to find someone who'll make the decisions I would have wanted to if I only had time. ;) -- brion vibber (brion @ wikimedia.org) CTO, Wikimedia Foundation San Francisco

2 2

tests in /phase3/t/inc/ now work. Patch attached to bug ticket 20112
by dan nessett 07 Aug '09

07 Aug '09

I have fixed 8 bugs (some fairly trivial) in /phase3/t/ so all of the tests in /t/inc/ now work. I have opened a bug ticket (20112) and attached a patch that fixes the bugs. I have not fixed problems with the tests in /t/maint/ because: 1) they seem to test OS functionality, not the MW software, and 2) they are written in PERL not PHP and my IDE (Netbeans 6.7.1) doesn't support PERL. Perhaps someone who has an IDE with PERL support will develop an interest in fixing them. This completes the task Brion asked me to take on. What happens next is up to the developer community. I have some ideas about test harness architecture (not radical ideas, but more than just fixing dings in the software) that I will run up the flag pole in subsequent posts. So far, only a few have responded to my posts (admittedly, some were a bit silly, such as the one asking where $wgLocalisationCacheConf is defined), but it seems few developers are interested in MW QA. Well, that isn't exactly unusual. Features are always more interesting that code stability. But, the history of software is littered with products possessing really neat features that eventually failed because developers did not take care of quality. Enough preaching.

1 0

PHPUnit tests now fixed
by dan nessett 07 Aug '09

07 Aug '09

I have fixed 5 bugs in /tests/ and added one feature to run-tests.php (a --runall option so testers can run the PHPUnit tests without using make - although make test still works). With these changes all of the tests in /tests/ now work. A unified diff patch is attached to bug ticket 20077. I had to make an architectural decision when enhancing run-test.php with the --runall option. The bug ticked describes this decision and suggests two other ways to achieve the same objective. I chose the approach implemented by the patch because it required no changes to the directory structure of /tests/. However, I actually prefer the second possibility. So, if senior developers could look at the bug ticket description and give me some feedback (especially if they also think the second option is better), that would be great. I also would appreciate some feedback on the following question. One of the tests referenced the global variables $wgDBadminname and $wgDBadminuser. When I ran the configuration script during Mediawiki installation on my machine, the LocalSettings.php file created defined the globals $wgDBname and $wgDBuser. So, I changed the test to use these variables rather than the 'admin' versions. However, I don't remember if the script gave me a choice to use the 'admin' versions or not. Also, if the configuration script has changed, then some installations may use the 'admin' versions and some may not. In either case, I would have to modify the bug fix to accept both types of global variable. If someone would fill me in, I can make any required changes to the bug fix.

6 10

Wiki@Home Extension
by Michael Dale 07 Aug '09

07 Aug '09

Want to point out the working prototype of the Wiki@home extension. Presently it focuses on a system for transcoding uploaded media to free formats, but will also be used for "flattening sequences" and maybe other things in the future ;) Its still rough around the edges ... it presently features: * Support for uploading a non-free media assets, * putting those non free media assets into a jobs table and distributing the transcode job into $wgChunkDuration length encoding jobs. ( each pieces is uploaded then reassembled on the server. that way big transcoding jobs can be distributed to as many clients that are participating ) * It supports multiple derivatives for different resolutions based on the requested size. ** In the future I will add a hook for oggHanlder to use that as well .. since a big usability issue right now is users embedding HD or high res ogg videos into a small video space in an article ... and it naturally it performs slowly. * It also features a JavaScript interface for clients to query for new jobs, get the job, download the asset, do transcode & upload it (all through an api module so people could build a client as a shell script if they wanted) ** In the future the interface will support preferences , basic statistics and more options like "turn on wiki@home every-time I visit wikipedia" or only get jobs while I am away from my computer. * I try and handle derivatives consistently with the "file"/ media handling system. So right now your uploaded non-free format file will be linked to on the file detail page and via the api calls. We should probably limit client exposure to non-free formats. Obviously they have the files be on a public url to be transcoded, but the interfaces for embedding and the stream detail page should link to the free format version at all times. * I tie transcoded chunks to user ids this makes it easier to disable bad participants. ** I need to add an interface to delete derivatives if someone flags it as so. * it supports $wgJobTimeOut for re-assigning jobs that don't get done in $wgJobTimeOut time. This was hacked together over the past few days so its by no means production ready ... but should get there soon ;) Feedback is welcome. Its in the svn at: /trunk/extensions/WikiAtHome/ peace, michael

14 46

How do I get $wgLocalisationCacheConf in scope for getLocalisationCache()?
by dan nessett 06 Aug '09

06 Aug '09

I am working on the tests in /t/. One, Revision.t, attempts to create a Language object and croaks in getLocalisationCache(), which is called by the Language class constructor. The problem is $wgLocalisationCacheConf is undefined, but referenced. When I Googled $wgLocalisationCacheConf I got the page: http://www.mediawiki.org/wiki/Manual:$wgLocalisationCacheConf It states that this global is introduced in 1.16.0. It isn't in my LocalSettings.php file (understandable, since I ran the install script on a version of MW prior to r52503, in which the variable is introduced). I'm not sure how the localization cache works, so would someone let me know what I have to do to get this variable in the scope of getLocalisationCache()? Thanks.

1 1

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 August 2009