Wikitech-l August 2009

wikitech-l@lists.wikimedia.org

94 participants
86 discussions

Friendly reminder
by Chad 04 Aug '09

04 Aug '09

Just a friendly note to all the new committers (and old ones who are lazy). Anyone who hasn't committed a USERINFO file to /svnroot/USERINFO is reminded that they should do so. It's used for managing the official "who has commit access" list at http://svn.wikimedia.org/users.php, and I'm not sure who else might be using these files for useful things. -Chad

1 0

Is there any evidence that the tests in phase3/maintenance/Tests ever worked?
by dan nessett 03 Aug '09

03 Aug '09

I am working on the tests in ../phase3/maintenance/tests. I have found 2 problems (one of which may be only locally relevant). When I follow the logic initiated in run-tests.php (which according to the target in the Makefile seems to be the initiator of the tests) there are a lot of includes, but nothing in these appears to lead to anything that might start the tests. I am beginning to suspect that these tests never worked. However, I am open to correction. Has anyone ever run these tests successfully?

3 5

GIF thumbnailing
by Ilmari Karonen 03 Aug '09

03 Aug '09

Currently, server side GIF thumbnailing on Wikimedia sites is disabled entirely by setting $wgMediaHandlers['image/gif'] = 'BitmapHandler_ClientOnly'; This causes all GIF files to be send to the browser at original size regardless of what size has been requested. While most folks seem to have pretty much resigned to the fact that animated GIFs can't be thumbnailed -- it never worked very well to begin with -- the fact that even static GIFs are sent at full resolution remains somewhat annoying, especially since people have uploaded some extremely large bitmaps in GIF format in the past. It seems to me that delivering *static* thumbnails of GIF images, either in GIF or PNG format, would be a considerable improvement over the current situation. And indeed, the code to do that seems to be already in place: just set $wgMaxAnimatedGifArea = 0; So, my questions would be: 1. Is there a reason we don't do this already? 2. If yes, and the reason is the GIF encoding causes too much load, would thumbnailing GIFs to PNG be better? It should only take a few lines of code to change the output format. 3. Alternatively, if the problem is ImageMagick taking too much time to read animated GIFs even just to extract only the first frame, would some other scaling program be better? Indeed, it should even be possible to write a bit of PHP code to pull out just the first frame of a GIF file and hand it off to ImageMagick for scaling. Ps. I'd also like to take the opportunity to remind everyone of the existence of https://bugzilla.wikimedia.org/show_bug.cgi?id=16451 and of the excellent-looking patch Werdna has written for it. We can do a _lot_ better with GIfs that we're currently doing. -- Ilmari Karonen

11 14

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

03 Aug '09

MediaWiki Bugzilla Report for July 27, 2009 - August 03, 2009 Status changes this week Bugs NEW : 216 Bugs ASSIGNED : 35 Bugs REOPENED : 31 Bugs RESOLVED : 170 Total bugs still open: 3789 Resolutions for the week: Bugs marked FIXED : 109 Bugs marked REMIND : 0 Bugs marked INVALID : 11 Bugs marked DUPLICATE : 21 Bugs marked WONTFIX : 24 Bugs marked WORKSFORME : 9 Bugs marked LATER : 4 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Site requests 9 server 7 LiquidThreads 5 Glossary 5 Special pages 4 New Bugs Per Product MediaWiki 16 Wikimedia 12 MediaWiki extensions 26 mwdumper 1 Wikipedia Mobile 7 Top 5 Bug Resolvers innocentkiller [AT] gmail.com 30 markus [AT] semantic-mediawiki.org 28 alex.emsenhuber [AT] bluewin.ch 16 JSchulz_4587 [AT] msn.com 10 agarrett [AT] wikimedia.org 10

1 0

Statistics now on MediaWiki page
by dan nessett 02 Aug '09

02 Aug '09

I am not finished with the analysis (MacGyver) tool, but I thought I would put up what I have so far on the MediaWiki site. I have created a web page in my user space for the Parser Test code coverage analysis - http://www.mediawiki.org/wiki/User:Dnessett/Parser_Tests/Code_Coverage I would appreciate it if someone familiar with the parser would at least glance at the per file statistics for a sanity check. Some things that worry me are: * parserTests seems to visit Special:Nuke. Does this make sense? * Only about 72% of Parser.php is exercised. Is this reasonable? * Xdebug is reporting that the Parser only has 2975 lines of executable code. This contrasts to the report by Happy-Mellon that there is 11,000 lines of code in Parser.php. Are there really that many non-executable lines of code in the parser or is Xdebug missing a whole bunch?

2 2

Extensions in Bugzilla
by Chad 01 Aug '09

01 Aug '09

Hey all, I've compiled a list[1] of extensions in Bugzilla that don't have a default assignee. If you want to be (or should already be) the assignee for any of these, please let me know. Would like to really cut that list down so bugs are getting triaged to someone who cares. Right now, they're all being assigned to wikibugs-l, and we know how many bugs he resolves :p -Chad [1] http://www.mediawiki.org/wiki/User:^demon/Unloved_extensions

6 11

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