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
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?
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
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?
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