Wikitech-l December 2010

wikitech-l@lists.wikimedia.org

95 participants
60 discussions

1.17 branched
by Roan Kattouw 08 Dec '10

08 Dec '10

You probably noticed, or heard in advance that it would happen, but I figured I'd announce it anyway: 1.17 was branched today. The branch is in /branches/REL1_17 and the branch point is r77974. When you commit or find a revision post-r77974 that you feel should be in 1.17 (bugfixes, typically, no new features), tag it with "1.17" in CodeReview. Please do this even if you're not afraid of SVN merging, so we can merge stuff in batches and keep the commit noise down. Nothing has been merged yet, although a few things seem to have been tagged already. When you find something pre-r77974 that you think should be backed out of 1.17 (i.e. reverted in the branch), tag it with "revert1.17". This shouldn't happen very often, so feel free to do this yourself if you know how. The only thing that's been backed out so far is a refactoring of the skin system in r77893. After merging/reverting, the tag should be removed. I'd also like to call upon everyone to help out with code review. Of course not everyone feels comfortable reviewing everything, but by all means review what you feel comfortable reviewing. Even if you're not an experienced reviewer/developer and only review trivial changes or changes to one specific component you're familiar with, you're taking work out of the hands of other reviewers. Roan Kattouw (Catrope)

3 4

Plea to get [Bug 21526 - Bug in Djvu text layer extraction] implemented
by Billinghurst 08 Dec '10

08 Dec '10

Can I again ask that the powers that be please assist to roll-out a bug fix that the Wikisource sites do need for a usability fix https://bugzilla.wikimedia.org/show_bug.cgi?id=21526 The bug was reported over a year ago, Reported: 2009-11-15 21:21 UTC by Simon Lipp and fixed five months ago ThomasV 2010-07-07 11:07:00 UTC Thanks for patch and the detailed explanation. I commited it (r69139) Implementation to servers? Unknown Requests for implementation? Ignored Any issues with means of implementation? Not known, not visible Systematic route to implementation? Seemingly not followed, and forgotten It is so incredibly frustrating to have to get continually ask for the simple fix to be put in place for a whole set of sister sites. It is so incredibly humiliating to almost to get down and beg that some consideration be given to some of the smaller sites. The utter silence that pervades these matters has moved from disregard and moving into disgraceful. That there is no communication or ability to even get an understanding of what can be expected is now well past disappointing and into unprofessional. I understand that there is a big picture to consider, however, there is the matter of consideration, courtesy and respect, and these very sadly seem to be missing. The situation seems to be going from neglect and moving towards something approaching culpability by the management system. If it is the noisy squeaky and disruptive that is the means to get something implemented, we can go there, however, surely, surely, surely, what we want is the polite and considerate. billinghurst ---------------------------------------------------------------- This message was sent using iSage/AuNix webmail http://www.isage.net.au/

3 2

Our skin system, and a skin's class name
by Daniel Friesen 07 Dec '10

07 Dec '10

I ran into an issue while experimenting with something today. I created a voidbook skin with a SkinVoidBook class which was going to be a test skin to duplicate monobook in a compiled template language. But I did it using the extension technique of setting $wgValidSkinNames and $wgAutoloadClasses like any other 3rd party skin. I ran into an issue with the skin not being loaded. After I debugged it I found out that for several years our skin system has been doing something utterly screwed up... Here's how Skin::newFromKey works with monobook. With $key = "monobook" passed to it the method Skin::getSkinNames() to get the fully filled $wgValidSkinNames data. $skinName becomes "MonoBook" and $className becomes "SkinMonobook" `$className = 'Skin' . ucfirst( $key );` The method does a class_exists triggering the autoloader checking for a "SkinMonobook" class. SkinMonobook is not found so the method loads up skins/MonoBook.php after optionally loading skins/MonoBook.deps.php, this loads the SkinMonoBook class. class_exists returns true, and so `new $className` is called... This creates an instance of SkinMonoBook from the $className SkinMonobook. See the screw up there? For a long time we've been sticking to naming our skin classes by the SkinMonoBook convention... while really, the skin system has been trying to load SkinMonobook and only succeeding because we use require_once directly loading SkinMonoBook and php's class system happens to be case insensitive so when we ask for SkinMonobook it gives us SkinMonoBook. Problem! Our autoloader is NOT case insensitive. So anyone following our internal conventions while trying to create a skin inside of an extension and they happen to decide on a skin name using a capital letter in the middle of the word gets a nasty suprise. Instead of the way it played out with MonoBook, VoidBook gets this result. $key = "voidbook"; Skin::newFromKey sets $skinName = "VoidBook"; $className = "SkinVoidbook"; class_name calls our autoloader asking for "SkinVoidbook", the class is actually SkinVoidBook so our autoloader does NOT load the class. The class_exists returns false, Skin::newFromKey continues along, doesn't see skins/SkinVoidBook.deps.php so it skips it... then it tires to require skins/SkinVoidBook.php, now because this is an extension based skin it trips up and we get a cryptic fatal php error. Now we've defined $wgValidSkinNames as an array mapping skin ids to names of those skins... however from what I see convention violates this notion. "cologne" is "CologneBlue" yet the skin's actual name is "Cologne Blue". "standard" is "Standard" yet the skin's actual name is "Classic". Despite the array being documented as a list of skin names, it really appears to conform to something that maps lower case skin ids to their proper cased counterparts which when prefixed with "Skin" will give you a skin's class name. While we use the i18n system for the real skin "name". This is actually fairly well supported by the fact that we use that skin "name" when we require a skin file from the skins folder. So to fix this bug I propose we change the documented format of $wgValidSkinNames to be an array mapping skin ids "monobook" to the proper cased key used for building class names and requiring files. And change `$className = 'Skin' . ucfirst( $key );` to `$className = "Skin{$skinName}";` so that "monobook" will try to load SkinMonoBook instead of SkinMonobook. As a side effect of this, it will also theoretically become possible to alias skins by doing something like `$wgValidSkinNames = "MonoBook";` which considering there are already cases in the wild where people have duplicated monobook to have varying styles like ReferenceBook, WhiteBook, etc... would probably be a desirable feature. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

1 0

Re: [Wikitech-l] Looking for a mediawiki.org dump
by Lars Buitinck 07 Dec '10

07 Dec '10

2010/12/6, wikitech-l-request(a)lists.wikimedia.org <wikitech-l-request(a)lists.wikimedia.org>: > Date: Mon, 6 Dec 2010 18:50:45 +1100 > From: Andrew Dunbar <hippytrail(a)gmail.com> > > Could anybody help me locate a dump of mediawiki.org while the dump > server is broken please? I only need current revisions. Use your Google-fu; there are some dumps available at various locations on the internet (archive.org, Pirate Bay). What is perhaps more important: can the checksums be made available somewhere while the dump server is down? That way, we can verify the dumps we must now fetch from untrusted sources. I hope the dump server goes back online soon, I need the SQL dumps for research into link mining... Regards, Lars Buitinck

1 0

Improving the skinning system
by Daniel Friesen 07 Dec '10

07 Dec '10

I've been chipping away at our skins system lately, there's a lot we can improve to improve the skins system. Right now there's a lot of it that doesn't work so nicely for an ecosystem promoting the creation of a wide variety of skins. - footerlinks is duplicated across skins and is hardcoded (I fixed this in trunk, I did footericons too, however these could be improved with helper methods, we still have unwanted boilerplate) - our directory structure is odd -- SkinName.php with skinname/ beside it means skins are not self enclosed and can't simply be dropped into their own directory -- having a first class skins directory we store skins in with proper autoloading, stylepath and localstylepath (1.17) variables, and having conventions for including skin resources like skins/{skinname}/path/to/file.ext but saying that any skin we don't include in core should instead go in extensions, use extensions assets path, not have localstylepath, and not use the skins/{skinname}/path/to/file.ext convention and be left without any autoloading at all, and include extra boilerplate/code that native skins don't need to, does not promote the creation of new third party skins --- in fact, besides the 4 skins in extensions/skins/ that were in svn which don't appear to be really notable skins and haven't been touched in a half year, all the 3rd party skins out there don't even use the extensions features, they all just have you place them inside skins/ the same way the native skins are. - we have page end boilerplate you have to copy into a skin (we can probably fix this somewhat similarly to the way headelement was added) - toolbox is hardcoded into the skin and needs to be copied (this one definitely should be fixed) - many of our toolboxes portlets nav links need very verbose loops and things hardcoded which would be better inside of a common helper method -- it should also be possible to differentiate between the page/talk and other navlinks the way vector does, without having to hardcode it or add a pile of extra php - building a sidebar should be minimal in the specialcases and php you have to hardcode (SEARCH, TOOLBOX, etc... special cases shouldn't be hardcoded into the skin) - we need a method of building a search form that is flexible to styles, but minimizes what you have to hardcode and what boilerplate you need, most skins should be able to call something and just drop a search box or search bar in with a single method if they don't want to do any special customization. - the large block of common boilerplate inside the content area also isn't that nice for building 3rd party skins I've been working on improving the system for the past few days. And I've also come up with a new idea for a skin packaging and installation convention. To show it off I ported WordPress' P2 theme into a wiki skin and committed it to http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/skins/p2wiki/ The result being http://trunk.new.wiki-tools.com/index.php?useskin=p2wiki The convention should work with currently stable versions of MediaWiki as well. And it is compatible with adding new features to newer versions of MediaWiki to tear away boilerplate necessary to package up a skin for distribution. As well as with $wgStylePath conventions. Currently the convention can be done by packaging up a skin like I did with p2wiki, using extension style techniques to add a new skin. It can be installed into skins/skinname/ and `require_once("$IP/skins/skinname/skinname.php");` can be added to LocalSettings.php. That convention will work in already released versions of MediaWiki. For future versions we may want to consider adding autoloading code for this style of skins, and adding some convention based defaults. As an ideal, it would be nice if some way down the road it's possible to build a skin without the use of any php, even if you have to enable an extension to add the actual template system or whatever. As for places for putting skins and distributing them, Lcawte proposed adding a /trunk/skins/ for the new convention. There was a bit of discussion in irc where some downsides, upsides, and counter issues were brought up. - Adding /trunk/skins would require some (possibly small?) changes to the Translation extension. - ExtensionDistributor would also need tweaks. -- However it was brought up that ExtensionDistributor doesn't work with /trunk/extensions/skins/ anyways, at least not if you're only trying to get one skin out. -- I think tweaking ExtensionDistributor to support /trunk/skins would be quite easy (at the simplest it's probably a case of making small tweaks to make a SkinDistributor that uses /trunk/skins instead of /trunk/extensions and whatnot) It's not part of distribution, but the new installer's ability to point out extensions and allow you to install them from the installer was pointed out. However generally each skin doesn't have it's own set of configuration (vector does, but generally as an ideal having a bunch of skins that are nothing but a separate theme for the site should not require special configuration of each one of them) so there isn't really much use for sharing configuration infrastructure. Additionally, if we do add an autoloader for the new style of skin there's not really any point to having the installer point out skins. If they're in a spot the installer can find them, they'll already be autoloaded anyways. Oh, and lastly... if anyone knows of any "really" good WordPress or other CMS themes or templates I might consider porting some as examples. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

4 5

Code review and making it to 1.17
by Rob Lanphier 06 Dec '10

06 Dec '10

Hi everyone, The code review team has been doing a fantastic job of clearing out the backlog, which you can see here: http://toolserver.org/~robla/crstats/crstats.html (uncheck "ok" on the checkboxes on the bottom to see new commits) There's some release planning issues that we have to sort out: 1. When will we branch 1.17? 2. When will we push 1.17wmf1 to production? 3. When will we release MediaWiki 1.17? Trevor and Roan believe that ResourceLoader will be ready to deploy in January. However, looking at the backlog of code reviews, and I don't think it's realistic to assume we'll have everything else ready in January. My assumption here is that we need to be through the code review backlog prior to pushing what is currently in trunk into production. Simply extrapolating from the October/November rate of code review, March is looking more like the target, and that assumes we keep up the rapid pace of review. What seems realistic without being complacent? One thing I think will help the rate of code review is for more developers to comment on commits more frequently. I know many of you already chime in on Code Review, which is great. If you can do your best job at providing a full code review (commenting rather than marking "ok"), that will hopefully catch some of the most immediate problems so that the code review team can focus on the more subtle issues and perhaps do a quicker review. Longer term, Roan has a new feature brewing to the Code Review system ("sign-offs") that will make it easier for you to provide some useful metadata for the code review team to use. With respect to MediaWiki 1.17 releases, I think we can actually release sooner after the first production deployment than we did after 1.16 if we pair our usual testing with some small amount formal QA and test automation (especially focusing on installer and a small amount of alternate DB testing [e.g. sqlite]) What seems realistic here? Longer term, everyone has stated a desire to move to more frequent deploys. I think that's a conversation worth having, but let's not have it as part of this thread. Thanks Rob

11 17

Bugzilla Weekly Report
by reporter 06 Dec '10

06 Dec '10

MediaWiki Bugzilla Report for November 29, 2010 - December 06, 2010 Status changes this week Bugs NEW : 197 Bugs ASSIGNED : 6 Bugs REOPENED : 31 Bugs RESOLVED : 123 Total bugs still open: 5225 Resolutions for the week: Bugs marked FIXED : 77 Bugs marked REMIND : 0 Bugs marked INVALID : 3 Bugs marked DUPLICATE : 18 Bugs marked WONTFIX : 16 Bugs marked WORKSFORME : 5 Bugs marked LATER : 6 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component UploadWizard 14 General/Unknown 9 CodeReview 6 Site requests 4 FlaggedRevs 3 New Bugs Per Product MediaWiki 24 Wikimedia 7 MediaWiki extensions 36 Wikipedia Mobile 2 Top 5 Bug Resolvers roan.kattouw [AT] gmail.com 21 diebuche [AT] gmail.com 21 sam [AT] reedyboy.net 13 JSchulz_4587 [AT] msn.com 7 jeluf [AT] gmx.de 5

1 0

Problem with MIME type detection
by Nicolas Vervelle 05 Dec '10

05 Dec '10

Hi, I want to authorize uploading of CML files<http://en.wikipedia.org/wiki/Chemical_Markup_Language>on my wiki <http://wiki.jmol.org/index.php/Main_Page>. These files have an XML format with a limited set of possible root elements. I would like them to be recognized by MediaWiki with a specific MIME type : chemical/x-cml I'm doing some tests on a virtual machine Ubuntu 10.10 with default MediaWiki setup (MW 1.15.5, PHP 5.3.3, MySql 5.1.49). I have done several modifications in the configuration : - $wgFileExtensions[] = 'cml'; in LocalSetting.php to allow the .cml extension - chemical/x-cml cml; in includes/mime.types to attach the MIME type to the extension - $wgXMLMimeTypes = array_merge( $wgXMLMimeTypes, array( ... ) ); in LocalSettings.php so that MimeMagic correctly detects CML files as chemical/x-cml When I upload the file, everything is ok and in the debug log the file seems correctly detected as chemical/x-cml. Even in the database, the file is stored with the correct MIME type. But when I display the File: page for this file, I see "MIME type: unknown/unknown" displayed by MediaWiki (same problem in the debug log). What do I need to do to have the MIME type correctly detected once the file is uploaded ? I want to develop a media handler for this kind of files, so I need to have correct Mime type detection. Thanks in advance. Nico

1 0

Draft plan for 1.17 branch next week (Code review and making it to 1.17)
by Rob Lanphier 05 Dec '10

05 Dec '10

Hi everyone, On IRC, Trevor lead the charge "to Etherpad!", and some of us followed. This was the result: http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17 This is an aggressive plan, starting with branching for 1.17 early next week. It is by no means official; Tim and Mark H are both named, but neither have weighed in, so don't take this as "the plan", but as a proposal for discussion here. Rob On Fri, Dec 3, 2010 at 2:35 PM, Trevor Parscal <tparscal(a)wikimedia.org> wrote: > Agreed - branching will not prevent bugs from getting fixed, we will be > merging in a limited set of changes (fixes to bug) while ignoring new > and irrelevant development. > > - Trevor > > On 12/3/10 2:26 PM, Roan Kattouw wrote: >> 2010/12/3 Platonides<Platonides(a)gmail.com>: >>> So if we can cope with reviewing, I would wait (I think >>> RobLa took it into account). Who will work into stabilizing the branch? >>> A branch will have less attention (bug hunting) than trunk >> Well to keep review catchup manageable, I think we need to either >> branch or declare something like a feature freeze and freeze for minor >> stuff in trunk. My general opinion on this sort of thing is that trunk >> should not generally be subject to such freezes. >> >> Roan Kattouw (Catrope) >> >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > >

5 7

Re: [Wikitech-l] Drafting the upcoming engineering overview
by howard jenkins 05 Dec '10

05 Dec '10

Do not block. The people of usa needs to know the truth. Plus our leaders be leading in a way that the people of the usa would like them too. Thank you. -----Original Message----- From: Rob Lanphier Sent: 9/23/2010 12:59:56 AM To: Wikimedia developers Subject: [Wikitech-l] Drafting the upcoming engineering overview Hi everyone, As you probably know, we're trying to get into the habit of providing a monthly overview of all WMF-sponsored engineering activity. The September update was posted to the techblog here: http://techblog.wikimedia.org/2010/09/wmf-engineering/ For October, we'd like to draft this in public so as to get the information out a little sooner, and to give you all the opportunity to help out. Here's where we're drafting this: http://www.mediawiki.org/wiki/WMF_Engineering_Overview_October_2010 Here's a very simple way you can help. If you see something on the list that you're interested in, but don't see the status for yet, ping one of us, then be bold and add what you learn to the appropriate wiki page. If you do know the status, by all means add it. Another useful thing to do: you'll notice that many of the project pages that the status post links to are pretty sparse. Same rules apply there. We'd love to get help keeping this up to date. Thanks! Rob _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

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 December 2010