Wikitech-l November 2011

wikitech-l@lists.wikimedia.org

127 participants
148 discussions

Code review goals for 1.19 deployment
by Rob Lanphier 28 Nov '11

28 Nov '11

Hi everyone, Here's an attempt at putting together a more sophisticated (though not necessarily correct) goal for 1.19: https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0Agte_lJNpi-OdD… The goal was not to make something 100% accurate based on our past record, but to come up with a goal that's informed by our history, but also nudges us a little to get better than before. During the 1.18 cycle, our goals were based on a linear review rate (same number of revisions every day). That may have been too easy on us in the early going. What was clear looking at the numbers from last time around was that, when focused on code review, the curve looked a lot more like an exponential decay curve (more reviews in the early going, tapering off toward the end). That's assuming that our backlog increase in July was an anomaly that we won't repeat. So, the 1.19 cycle has new review goals that are based on exponential decay curve, with a linear fudge factor built in so that we don't just approach zero, but make it there. Fixmes, however, did seem to have a linear rate during the 1.18 cycle, so I left our goals linear for this release. I've accounted for a plateau in the last two weeks of December when many WMF staff will likely be taking holiday vacation. The goal is to get done with review by January 31, 2012. While this is much later than we were previously hoping for, it's still pretty aggressive given the backlog we have. This assumes that the huge swath of revisions that Hashar marked "deferred" on Friday all stay deferred, for example, and that we'll still find other pockets of revisions that we can use to knock off 50+ revs a day in the early going. Does this look like a workable goal to everyone? Assuming so, we'll report our progress against this goal, and plan the 1.19 deploy for early February. Rob

2 1

Bugzilla Weekly Report
by reporter 28 Nov '11

28 Nov '11

MediaWiki Bugzilla Report for November 21, 2011 - November 28, 2011 Status changes this week Bugs NEW : 411 Bugs ASSIGNED : 9 Bugs REOPENED : 61 Bugs RESOLVED : 137 Total bugs still open: 6600 Resolutions for the week: Bugs marked FIXED : 79 Bugs marked REMIND : 0 Bugs marked INVALID : 35 Bugs marked DUPLICATE : 7 Bugs marked WONTFIX : 15 Bugs marked WORKSFORME : 4 Bugs marked LATER : 2 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component General/Unknown 7 MobileFrontend 6 Site requests 6 Semantic MediaWiki 5 General/Unknown 4 New Bugs Per Product MediaWiki 21 Wikimedia 21 MediaWiki extensions 33 Wikimedia Mobile 6 CiviCRM 1 Top 5 Bug Resolvers tim.starling [AT] rocketmail.com 77 innocentkiller [AT] gmail.com 22 sam [AT] reedyboy.net 8 john [AT] compwhizii.net 8 jeroen_dedauw [AT] yahoo.com 7

4 3

Re: [Wikitech-l] Final mobile switch-over
by bawolff 28 Nov '11

28 Nov '11

> Message: 2 > Date: Wed, 16 Nov 2011 01:48:48 +0900 > From: Philip Chang <pchang(a)wikimedia.org> > Subject: [Wikitech-l] Final mobile switch-over > To: wikipedia-l(a)lists.wikimedia.org, wiktionary-l(a)lists.wikimedia.org, > wikiquote-l(a)lists.wikimedia.org, textbook-l(a)lists.wikimedia.org, > wikisource-l(a)lists.wikimedia.org, wikinews-l(a)lists.wikimedia.org, > wikiversity-l(a)lists.wikimedia.org, wikispecies-l(a)lists.wikimedia.org, > wikitech-l(a)lists.wikimedia.org, commons-l(a)lists.wikimedia.org, > incubator(a)lists.wikimedia.org > Message-ID: > <CAE1jH8LD=drV79wNb4iJMGm9_XYxCh7b5rPFEpKyhfY+gmuuiQ(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > TO: All Wikimedia Project Administrators > > > As a follow-up to this original blog post about the new mobile site: > > http://blog.wikimedia.org/2011/09/14/new-mobile-site-launched-on-wikipedia-… > > Please note that the conversion to the new Mobile Frontend extension will > be completed in the week of November 28. > > This means that by default any user of a mobile device will see the mobile > interface rather then the desktop version. Users will no longer have to add > the extra .m by hand. > > This also means any home pages not yet designed for mobile viewing will > appear with a search bar only - unless you create a home page in the next > three weeks, which is very easy to do! > > Instructions for creating a home page are here: > > http://meta.wikimedia.org/wiki/Mobile_Projects/Mobile_Gateway#Mobile_homepa… > > Please forward this email as necessary. > > As always, the mobile-l and mobile-feedback-l mailing lists are available. > There will be many more announcements in the coming months on mobile-l, and > always feel free to send comments to mobile-feedback-l. > > Thank you. > > Phil > > -- > Phil Inje Chang > Product Manager, Mobile > Wikimedia Foundation > 415-812-0854 m > 415-882-7982 x 6810 Surely it would make more sense for the mobile frontend to detect that no ids match the looked for pattern and treat the main page as a normal page in that case instead of totally and utterly breaking if the admin didn't customize the front page properly? -bawolff

4 5

Extracting text from Wikipedia
by Khalida BEN SIDI AHMED 28 Nov '11

28 Nov '11

Hello! I don't know if the subject of this question belongs to the scope of this group. Anyway, I will be pleased if I find an aswer to my question. I'm writing some Java code in order to realize NLP tasks upon texts using Wikipedia. What can I do in order to extract the first paragraph of a Wikipedia article? Thanks a lot. Truly yours Ben Sidi Ahmed

4 13

Adding MD5 / SHA1 column to revision table (discussing r94289)
by Diederik van Liere 28 Nov '11

28 Nov '11

Hi! I am starting this thread because Brion's revision r94289 reverted r94289 [0] stating "core schema change with no discussion" [1]. Bugs 21860 [2] and 25312 [3] advocate for the inclusion of a hash column (either md5 or sha1) in the revision table. The primary use case of this column will be to assist detecting reverts. I don't think that data integrity is the primary reason for adding this column. The huge advantage of having such a column is that it will not be longer necessary to analyze full dumps to detect reverts, instead you can look for reverts in the stub dump file by looking for the same hash within a single page. The fact that there is a theoretical chance of a collision is not very important IMHO, it would just mean that in very rare cases in our research we would flag an edit being reverted while it's not. The two bug reports contain quite long discussions and this feature has also been discussed internally quite extensively but oddly enough it hasn't happened yet on the mailinglist. So let's have a discussion! [0] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94289 [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94541 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=21860 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=25312 Best, Diederik

19 28

Html code
by Khalida BEN SIDI AHMED 27 Nov '11

27 Nov '11

Hello! In the html code of a Wikipedia article how to recognise the *first*sentence of this article?

3 3

Eliminating Article to fix a mistake, and now making a new mistake?
by Daniel Friesen 27 Nov '11

27 Nov '11

The Article class was a problem we've been trying to fix. Article basically was 3 things rolled all into one: 1) A page generation class that when run would fill up OutputPage 2) A context that references a Title, of course using the global $wg context for the rest at the time 3) A glorified Title, containing helpers for doing article related things Taking the place of 1) we have things like SpecialPage, Action, and some things that are still left inside Article. (I'm hoping to eliminate Action and Article with the pageoutput branch though.) Taking the place of 2) we have a RequestContext system. Instead of hoarding information to itself the classes that fill up OutputPage make use of a context. Taking the place of 3) we have WikiPage. However, I'm starting to see a new pattern in the quest to eliminate Article that's making a brand new mistake. function __constructor( Page $page, IContextSource $context = null ) { ... } People seam to be changing constructors for (1) type things that fill up OutputPage that once took an Article into one that takes a WikiPage and a RequestContext, in situations where a Context should be enough information. WikiPage is basically a glorified title. It takes a single title, and provides access to a number of helpers for that title, such as fetching content, and other information. Anyone with a title can get a WikiPage perfectly usable for their purposes by calling WikiPage::factory( $title ); WikiPage has ABSOLUTELY no user state to it. There is no setXYZ on WikiPage that would make one WikiPage unique from another WikiPage obtained from the same title and warrant keeping WikiPage around. The only /state/ WikiPage has is a few member variables to cache information about the title it's fetched from the database, such as the contents of the revision so that it doesn't keep re-fetching them. The ONLY reason I see to pass a WikiPage when you already have a Title is so that the WikiPage instance you have doesn't lose the cached stuff like revision that it already fetched from the database. ---- I'd like to propose a different pattern. Because WikiPage is basically a glorified Title we move our pattern for getting ahold of a WikiPage to where we get our title. In other words, we add RequestContext::getWikiPage which will run WikiPage::factory( $this->getTitle() ); to get the WikiPage relevant to a Title. If setTitle is used on that RequestContext we unset the WikiPage we have on RequestContext since the title has changed. ((Unless someone thinks that it would be a better idea for WikiPage::factory or whatever we call it to only create a singleton instance per-title. ie: `WikiPage::factory( Title::newFromText( 'Asdf' ) === WikiPage::factory( Title::newFromText( 'Asdf' );`)) Our page generation classes like Action, etc... accept a Context. If they need a WikiPage to access the Title helpers they use getWikiPage on the context they are working in. In the case where we need to tell a output page generating class to use a different title than the one we have in our context, we make use of a proper DerivativeContext instead of handing it a WikiPage for a different title than the context and utterly confusing it. For example, if we had Special:History/Foo as our title and wanted to run HistoryPage with a context of "Foo" as a title: $pageContext = new DerivativeContext( $context ); $pageContext->setTitle( Title::newFromText( 'Foo' ) ); $... = new HistoryPage( $pageContext ); -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

1 0

Forbidden access
by Khalida BEN SIDI AHMED 26 Nov '11

26 Nov '11

For my research I need to download 3 files: - [LANGCODE]wiki-[DATE]-pages-articles.xml.bz2 *OR* [LANGCODE]wiki-[DATE]-pages-meta-current.xml.bz2 - [LANGCODE]wiki-[DATE]-pagelinks.sql.gz - [LANGCODE]wiki-[DATE]-categorylinks.sql.gz I downloaded the 2 first ones. Now I can not have an access to all download pages (eg. http://dumps.wikimedia.org/enwiki/). The browser shows this message : 403-Fobidden. I need to know why the access is naw forbidden and how to solve this problem.

4 8

Java script devs needed :)
by Petr Bena 26 Nov '11

26 Nov '11

Hi folks, I got some quick review from Bawolff for the extension OnlineStatusBar I've been working on past weeks, the extension is allowing users to display their online status on user pages and have some support on english wikipedia for its deployment there, since it wasn't reviewed for deployment yet it's unlike it would happen soon, but there is a chance it could be installed in the future once it's ready and all issues fixed, (many users on wikipedia are already using custom statuses by editing their userpage everytime when they log in or logout so it could be useful as a replacement for that). He noticed that it would be cool if there was a js menu for it to let users pick the status (away etc.) instead of opening preferences. I like it but unfortunately I don't understand js even a bit. So if there was someone who was able to help with that, it would be very nice! The extension is in /trunk/extensions/OnlineStatusBar so if you got an idea how to make it, valid and secure so it wouldn't cause problems if it was eventually deployed to wmf wiki(s) please go ahead :) feel free to insert your name in the about in that case. Thanks, Peter

2 4

Path routing code changed, WebRequestGetPathInfoRequestURI replaced
by Daniel Friesen 26 Nov '11

26 Nov '11

The hook I introduced in r94373 ('WebRequestGetPathInfoRequestURI') for extending path routing has been dropped in r104274 and replaced with some new code. We now have a path routing class. This class is instanced inside of WebRequest, the hook WebRequestPathInfoRouter is called with it as the argument. And then it's used to parse the REQUEST_URI. Instead of the previous verbose method an extension can now extend our REQUEST_URI parsing by adding patterns to the PathRouter in that hook like so: $router->add( "/wiki/$1" ); $router->add( array( 'edit' => "/edit/$1" ), array( 'action' => '$key' ) ); $router->add( "/$2/$1" ), array( 'variant' => '$2' ), array( '$2' => array( 'zh-hant', 'zh-hans', ... ) ) ); $router->addStrict( "/foo/Bar", array( 'title' => 'Baz' ) ); $router->add( "/help/$1", array( 'title' => 'Help:$1' ) ); Don't worry about the order that you specify patterns. This new path router parses based on how specific the pattern is, so "/wiki/$1" will always dominate "/$1", and a "/$2/$1" where $2 is restricted to 'foo' and 'bar' will always dominate a "/$2/$1" with no restrictions. [r94373]: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/94373 [r104274]: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/104274 -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

1 0

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

Jump to page:

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 November 2011