[MediaWiki-CodeReview] [MediaWiki r114799]: Revision status changed

[MediaWiki Mail]

"Nikerabbit" changed the status of MediaWiki.r114799 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114799

Old status:  new
New status: ok

Commit summary for MediaWiki.r114799:

Remove support for deleted Wikia MediaWiki extension.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114798]: Revision status changed

[MediaWiki Mail]

"Nikerabbit" changed the status of MediaWiki.r114798 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114798

Old status:  new
New status: ok

Commit summary for MediaWiki.r114798:

Update tags.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Daring to consider replacing gerrit (help write gareth)

[Erik Moeller]

On Sun, Apr 8, 2012 at 7:26 PM, John Du Hart  wrote:

>> Meanwhile, dont waste your time coding something we are most certainly
>> never going to use.

> Statements like that from WMF staff are hurtful towards volunteer
> developers. Don't turn this into another MobileFrontend situation.

Antoine's welcome to speak his mind freely, like anyone; there's no
party line. I agree with him that we're unlikely to invest any
significant effort in this unless it gains substantial traction and
starts to look like a real alternative. But I don't think Daniel was
asking for that -- he wants to give it a go, and get others excited
about it. Which is awesome, and exactly what Labs was made for. :-)

WMF is likely going to focus its efforts on participating more in the
gerrit development process and evaluating existing alternatives.
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Bugzilla Weekly Report

[reporter]

MediaWiki Bugzilla Report for April 02, 2012 - April 09, 2012

Status changes this week

Bugs NEW   :  281 
Bugs ASSIGNED  :  21  
Bugs REOPENED  :  38  
Bugs RESOLVED  :  117 

Total bugs still open: 7533

Resolutions for the week:

Bugs marked FIXED  :  92  
Bugs marked REMIND :  0   
Bugs marked INVALID:  6   
Bugs marked DUPLICATE  :  11  
Bugs marked WONTFIX:  6   
Bugs marked WORKSFORME :  1   
Bugs marked LATER  :  1   
Bugs marked MOVED  :  0   

Specific Product/Component Resolutions & User Metrics 

New Bugs Per Component

Generic 19  
Site requests   8   
OTRS5   
Images and files5   
Git/Gerrit  5   

New Bugs Per Product

MediaWiki   37  
Wikimedia   23  
MediaWiki extensions31  
Security2   
Wikimedia Labs  2   

Top 5 Bug Resolvers

sam [AT] reedyboy.net   17  
mah [AT] everybody.org  8   
rlane32 [AT] gmail.com  6   
brion [AT] wikimedia.org6   
pfhayes [AT] gmail.com  5   


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Daring to consider replacing gerrit (help write gareth)

[Sumana Harihareswara]

On 04/08/2012 10:23 PM, John Du Hart wrote:
> So what happened to considering Phabricator in the future?

That evaluation is going to happen in June.  It's on the roadmap for us
to lead then: https://www.mediawiki.org/wiki/Roadmap#Platform

-- 
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Daring to consider replacing gerrit (help write gareth)

[John Du Hart]

On Sun, Apr 8, 2012 at 4:18 PM, Antoine Musso  wrote:
> Meanwhile, dont waste your time coding something we are most certainly
> never going to use.

Statements like that from WMF staff are hurtful towards volunteer
developers. Don't turn this into another MobileFrontend situation.

-- 
John

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Daring to consider replacing gerrit (help write gareth)

[John Du Hart]

So what happened to considering Phabricator in the future?

On Sun, Apr 8, 2012 at 5:29 PM, Platonides  wrote:
> On 08/04/12 22:49, Daniel Friesen wrote:
 - The project needs a good database system. I copied our database
 classes in but never got to using them. I'm isolating all database stuff
 into some model classes so different database handing can be swapped in.
 Anyone who feels up to it can adapt our database code to work as a
 framework for the review system.
>>>
>>> I think it would be easier with our classes. Too much fetch()s in
>>> ProjectModel.php
>>
>> Someone would need to adapt the classes to work outside MW.
>> I started using Mysqli and prepared statements since it's an easy way to
>> get the database stuff out of the way right away.
>
> I think they work. You do:
>
> $conf = array( 'host' => ..., 'user' => ..., 'pass'=> ..., 'dbname'
> =>..., 'tableprefix'=> ... )
> $db = Database::factory( 'mysql', $conf );
>
> And you have a perfectly working Database object.
>
> Or if you prefer something much more lightweight,
>  https://fisheye.toolserver.org/browse/erfgoed/api/includes/Database.php?hb=true
> is a Database class which aims to provide a similar interface to ours.
>
>
 - Right now I'm implementing git handling using proc_open to interact
 with git's porcelain and plumbing commands. Anyone who feels up to the
 task is free to implement a PHP extension for interfacing with git we
 can swap over to using.
>>>
>>> Please, remove the usage of __call() there. Make a different function
>>> for each one, even if they're going to be dummy ones right now.
>>> This way we can easily replace them with real implementations instead of
>>> wondering which ones are called by the magic.
>>
>> Drop ShellGit entirely and make Git the only class?
>
> No, I mean:
> function diff() {
>   return call_user_func_array( array( $this->git, __METHOD__ ),
> get_func_args() );
> }
>
> function show() {
>   return call_user_func_array( array( $this->git, __METHOD__ ),
> get_func_args() );
> }
>
> etc.
>
> (still, I think ShellGit misses a __call and won't work right now)
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
John

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Daring to consider replacing gerrit (help write gareth)

[Platonides]

On 08/04/12 22:49, Daniel Friesen wrote:
>>> - The project needs a good database system. I copied our database
>>> classes in but never got to using them. I'm isolating all database stuff
>>> into some model classes so different database handing can be swapped in.
>>> Anyone who feels up to it can adapt our database code to work as a
>>> framework for the review system.
>>
>> I think it would be easier with our classes. Too much fetch()s in
>> ProjectModel.php
> 
> Someone would need to adapt the classes to work outside MW.
> I started using Mysqli and prepared statements since it's an easy way to
> get the database stuff out of the way right away.

I think they work. You do:

$conf = array( 'host' => ..., 'user' => ..., 'pass'=> ..., 'dbname'
=>..., 'tableprefix'=> ... )
$db = Database::factory( 'mysql', $conf );

And you have a perfectly working Database object.

Or if you prefer something much more lightweight,
 https://fisheye.toolserver.org/browse/erfgoed/api/includes/Database.php?hb=true
is a Database class which aims to provide a similar interface to ours.


>>> - Right now I'm implementing git handling using proc_open to interact
>>> with git's porcelain and plumbing commands. Anyone who feels up to the
>>> task is free to implement a PHP extension for interfacing with git we
>>> can swap over to using.
>>
>> Please, remove the usage of __call() there. Make a different function
>> for each one, even if they're going to be dummy ones right now.
>> This way we can easily replace them with real implementations instead of
>> wondering which ones are called by the magic.
> 
> Drop ShellGit entirely and make Git the only class?

No, I mean:
function diff() {
   return call_user_func_array( array( $this->git, __METHOD__ ),
get_func_args() );
}

function show() {
   return call_user_func_array( array( $this->git, __METHOD__ ),
get_func_args() );
}

etc.

(still, I think ShellGit misses a __call and won't work right now)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skipping the review step for certain extensions

[Jeroen De Dauw]

Hey,

> We can allow people to push directly in the repository without having
Gerrit to "intercept" the commit.

Right, I looked a bit through gerrits docs and figured I actually have the
rights for my extensions to enable myself to do this, using this stuff:

https://review.typo3.org/Documentation/access-control.html#category_push_merge

Might be good to document this somewhere, assuming this is the correct
approach :)

> if the other core SMW devs put their names down at
https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership then we'll
process them within a couple of days

Luckily this is not needed. I'd like to point out that any situation where
people managing a project don't have such access and would need to rely on
people from outside their community to get things done is bad and might
very well incentivise them to not use WMFs gerrit.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Daring to consider replacing gerrit (help write gareth)

[Daniel Friesen]

On Sun, 08 Apr 2012 13:32:07 -0700, Platonides   
wrote:



You're a brave soul!
Can we get a labs project for testing that in real time?


I'm not sure about the personal public remotes. If we're going to
continue with our way of contribution, we would have continuous bases.
OTOH it looks cool to be able to work A1--A2--B1--B2 without creating
new branches at each step.

Well, you can work that way. Though I think gareth will still have similar
handling where using a branch name makes the review system automatically
guess what name to use for the topic/review branch.

It also shields you from some unnecessary merge conflicts.


The review-heads stuffs is perhaps too complicated. I think it'd be
simpler to base in the well-known monotonic-increased ids.
So the review-queue item 1024 is at refs/review-heads/1024 where you
pull the latest item (or the full set?), and each forked head for that
review has refs/review-heads/1024/1, refs/review-heads/1024/2...
Plus the aliasing of 1024 to Voice-to-wikitext-feature.

Reuse of old names might be confusing. Maybe if a name is reused it
should get named Feature_v2 and the original one automatically named
Feature_v1. The mere presence of v2 indicates that there was a prior one.


Hmm... I'll consider it. But this project's focus has been trying to
embrace the git way of doing things; since some of gerrit's issues stem
from ignoring that way of doing things.


- The project needs a good database system. I copied our database
classes in but never got to using them. I'm isolating all database stuff
into some model classes so different database handing can be swapped in.
Anyone who feels up to it can adapt our database code to work as a
framework for the review system.


I think it would be easier with our classes. Too much fetch()s in
ProjectModel.php


Someone would need to adapt the classes to work outside MW.
I started using Mysqli and prepared statements since it's an easy way to
get the database stuff out of the way right away.


- Right now I'm implementing git handling using proc_open to interact
with git's porcelain and plumbing commands. Anyone who feels up to the
task is free to implement a PHP extension for interfacing with git we
can swap over to using.


Please, remove the usage of __call() there. Make a different function
for each one, even if they're going to be dummy ones right now.
This way we can easily replace them with real implementations instead of
wondering which ones are called by the magic.


Drop ShellGit entirely and make Git the only class?

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Daring to consider replacing gerrit (help write gareth)

[Platonides]

You're a brave soul!
Can we get a labs project for testing that in real time?


I'm not sure about the personal public remotes. If we're going to
continue with our way of contribution, we would have continuous bases.
OTOH it looks cool to be able to work A1--A2--B1--B2 without creating
new branches at each step.


The review-heads stuffs is perhaps too complicated. I think it'd be
simpler to base in the well-known monotonic-increased ids.
So the review-queue item 1024 is at refs/review-heads/1024 where you
pull the latest item (or the full set?), and each forked head for that
review has refs/review-heads/1024/1, refs/review-heads/1024/2...
Plus the aliasing of 1024 to Voice-to-wikitext-feature.

Reuse of old names might be confusing. Maybe if a name is reused it
should get named Feature_v2 and the original one automatically named
Feature_v1. The mere presence of v2 indicates that there was a prior one.


> - The project needs a good database system. I copied our database
> classes in but never got to using them. I'm isolating all database stuff
> into some model classes so different database handing can be swapped in.
> Anyone who feels up to it can adapt our database code to work as a
> framework for the review system.

I think it would be easier with our classes. Too much fetch()s in
ProjectModel.php



> - Right now I'm implementing git handling using proc_open to interact
> with git's porcelain and plumbing commands. Anyone who feels up to the
> task is free to implement a PHP extension for interfacing with git we
> can swap over to using.

Please, remove the usage of __call() there. Make a different function
for each one, even if they're going to be dummy ones right now.
This way we can easily replace them with real implementations instead of
wondering which ones are called by the magic.





___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Daring to consider replacing gerrit (help write gareth)

[Antoine Musso]

Le 08/04/12 14:44, Daniel Friesen wrote :
> We're using gerrit now. And as we use it we all keep running into issues
> stemming fundamentally from how gerrit is designed.


Hello Daniel,

We already had the experience of writing a code review tool from scratch
and although it filled a need at that time, I am not going to regret it.

I do not think the foundation should fund the project of writing a new
app from scratch which probably nobody else will use anyway and based on
a niche Framework which is MediaWiki.  Instead we should  stick to
reuses existing tools and have them enhanced to fit our needs, writing a
whole new app should be a solution of last resort.

Before starting to write code in a rush, your really first step should
be to find out what is *functionally* wrong with Gerrit and find out
what we need.  I have yet to find out anyone describing what is wrong
with Gerrit although we all have a sentiment that the UI is confusing
and some obvious technical issues.  They do not justify a rewrite in my
opinion.

Once you have a list of requirements, though, we could look at the
possibility of fixing Gerrit to fit our needs. If that is not possible,
we could use that list as a basis to find out another tool.  You could
coordinate with John Du Hart who has been working on Phabricator, a
suite of tools from Facebook which include a code review tool as I
understand it.  Other examples that comes to mind are GitHub and Gitorious.

Meanwhile, dont waste your time coding something we are most certainly
never going to use.

cheers,

-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Daring to consider replacing gerrit (help write gareth)

[Antoine Musso]

Le 08/04/12 14:44, Daniel Friesen a écrit :
> anyone who feels that a framework they know fits best and wants to make
> the review system use it (Though no file layout controlling MVC
> frameworks, please).

For a PHP framework, have a look at Symfony:
 http://www.symfony-project.org/

If I wanted to write a web application from scratch, I would use
JavaScript with node.js.

-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skipping the review step for certain extensions

[Sumana Harihareswara]

On 04/08/2012 03:40 PM, Antoine Musso wrote:
> Le 08/04/12 20:27, Jeroen De Dauw a écrit :
>> Most of my extensions have been migrated to the new git setup with gerrit.
>> I'm not happy with the workflow for the extensions where I'm basically the
>> only real contributor or those where no one is going to review my stuff
>> anyway. Although I can approve my own changes and merge them in, this is
>> rather silly. Is there a way to disable the review step for certain
>> extensions (ie post comit review instead of gated trunk), and is it
>> possible to automatically merge in commits of certain users? For example in
>> case of Semantic MediaWiki, I'd like my commits and those of the other core
>> SMW devs to be merged in without first needing a review, while commits of
>> random other people should require review first.
> 
> Hello Jeroen
> 
> To create a change in Gerrit, one has to push a reference to a specific
> path starting by:  refs/for/.  To enforce the use of Gerrit we have it
> disallow any push out of refs/for :-D
> 
> We can allow people to push directly in the repository without having
> Gerrit to "intercept" the commit.  We can even make a group of people
> allowed to push without review, another one allowed to tag release and
> another group which can only push to refs/for/*.
> 
> I am not sure what is the process to requests access changes, Sumanah
> could tell about it. Meanwhile, you can ask ^demon about it.
> 
> cheers,

Jeroen, if the other core SMW devs put their names down at
https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership then we'll
process them within a couple of days, so they can have the ability to
merge commits into the SMW extensions (and veto/abandon commits as well).

I will defer to Chad, Antoine, and Ryan regarding "automatically +2 and
merge only these committers' merge requests" configuration.

-- 
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skipping the review step for certain extensions

[Antoine Musso]

Le 08/04/12 20:27, Jeroen De Dauw a écrit :
> Most of my extensions have been migrated to the new git setup with gerrit.
> I'm not happy with the workflow for the extensions where I'm basically the
> only real contributor or those where no one is going to review my stuff
> anyway. Although I can approve my own changes and merge them in, this is
> rather silly. Is there a way to disable the review step for certain
> extensions (ie post comit review instead of gated trunk), and is it
> possible to automatically merge in commits of certain users? For example in
> case of Semantic MediaWiki, I'd like my commits and those of the other core
> SMW devs to be merged in without first needing a review, while commits of
> random other people should require review first.

Hello Jeroen

To create a change in Gerrit, one has to push a reference to a specific
path starting by:  refs/for/.  To enforce the use of Gerrit we have it
disallow any push out of refs/for :-D

We can allow people to push directly in the repository without having
Gerrit to "intercept" the commit.  We can even make a group of people
allowed to push without review, another one allowed to tag release and
another group which can only push to refs/for/*.

I am not sure what is the process to requests access changes, Sumanah
could tell about it. Meanwhile, you can ask ^demon about it.

cheers,

-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Page views

[emijrp]

2012/4/8 Erik Zachte 

> Hi Lars,
>
> You have a point here, especially for smaller projects:
>
> For Swedish Wikisource:
>
> zcat sampled-1000.log-20120404.gz | grep  'GET http://sv.wikisource.org' |
> awk '{print $9, $11,$14}'
>
> returns 20 lines from this 1:1000 sampled squid log file
> after removing javascript/json/robots.txt there are 13 left,
> which fits perfectly with 10,000 to 13,000 per day
>
> however 9 of these are bots!!
>
>
How many of that 1000 sample log were robots (including all languages)?

-- 
Emilio J. Rodríguez-Posada. E-mail: emijrp AT gmail DOT com
Pre-doctoral student at the University of Cádiz (Spain)
Projects: AVBOT  |
StatMediaWiki
| WikiEvidens  |
WikiPapers
| WikiTeam 
Personal website: https://sites.google.com/site/emijrp/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Page views

[Erik Zachte]

Hi Lars,

You have a point here, especially for smaller projects:

For Swedish Wikisource:

zcat sampled-1000.log-20120404.gz | grep  'GET http://sv.wikisource.org' |
awk '{print $9, $11,$14}' 

returns 20 lines from this 1:1000 sampled squid log file
after removing javascript/json/robots.txt there are 13 left, 
which fits perfectly with 10,000 to 13,000 per day 

however 9 of these are bots!!

http://sv.wikisource.org/wiki/Snabbt_jagar_stormen_v%C3%A5ra_%C3%A5r,text/ht
ml,Mozilla/5.0%20(Macintosh;%20Intel%20Mac%20OS%20X%2010_7_2)%20AppleWebKit/
535.19%20(KHTML,%20like%20Gecko)%20Chrome/18.0.1025.142%20Safari/535.19
http://sv.wikisource.org/wiki/Special:Log?page=User:Sarahmaethomas,text/html
,Mozilla/5.0%20(compatible;%20Googlebot/2.1;%20+http://www.google.com/bot.ht
ml)
http://sv.wikisource.org/wiki/Underbar-k%C3%A4rlek-s%C3%A5-stor,text/html,Mo
zilla/5.0%20(compatible;%20Googlebot/2.1;%20+http://www.google.com/bot.html)
http://sv.wikisource.org/w/index.php?title=Diskussion%3aBer%c3%a4ttelser+ur+
svenska+historien%2fHedniska+tiden%2f2&redirect=no&action=raw&ctype=text/pla
in&dontcountme=s,text/x-wiki,DotNetWikiBot/2.97%20(Microsoft%20Windows%20NT%
206.1.7601%20Service%20Pack%201;%20.NET%20CLR%202.0.50727.5448)
http://sv.wikisource.org/wiki/Sida:SOU_1962_36.djvu/36,-,Mozilla/5.0%20(comp
atible;%20Googlebot/2.1;%20+http://www.google.com/bot.html)
http://sv.wikisource.org/wiki/Till_Polen,-,Mozilla/5.0%20(compatible;%20Goog
lebot/2.1;%20+http://www.google.com/bot.html)
http://sv.wikisource.org/wiki/Bibeln_1917/F%C3%B6rsta_Moseboken,text/html,Mo
zilla/5.0%20(Macintosh;%20Intel%20Mac%20OS%20X%2010_7_3)%20AppleWebKit/534.5
3.11%20(KHTML,%20like%20Gecko)%20Version/5.1.3%20Safari/534.53.10
http://sv.wikisource.org/wiki/Arbetare,text/html,Mozilla/5.0%20(compatible;%
20YandexBot/3.0;%20+http://yandex.com/bots)
http://sv.wikisource.org/wiki/Industrin_och_kvinnofr,text/html,Mozilla/5.0%2
0(compatible;%20Baiduspider/2.0;%20+http://www.baidu.com/search/spider.html)
http://sv.wikisource.org/wiki/Sida:Berzelius_Reseanteckningar_1903.djvu/120,
text/html,Mozilla/5.0%20(compatible;%20Googlebot/2.1;%20+http://www.google.c
om/bot.html)
http://sv.wikisource.org/wiki/Kategori:Ordspr%C3%A5ksboken,text/html,Mozilla
/5.0%20(compatible;%20MSIE%209.0;%20Windows%20NT%206.1;%20Win64;%20x64;%20Tr
ident/5.0)
http://sv.wikisource.org/wiki/Special:L%C3%A4nkar_hit/Kategori:Karin_Boye,te
xt/html,Mozilla/5.0%20(compatible;%20YandexBot/3.0;%20+http://yandex.com/bot
s)
http://sv.wikisource.org/wiki/Sida:Om_arternas_uppkomst.djvu/235,-,Mozilla/5
.0%20(compatible;%20YandexBot/3.0;%20+http://yandex.com/bots)

The page view report
http://stats.wikimedia.org/wikisource/EN/TablesPageViewsMonthlyOriginal.htm 
is based on 
http://dumps.wikimedia.org/other/pagecounts-raw/2012/2012-04/ 
collected by 
http://svn.wikimedia.org/viewvc/mediawiki/trunk/webstatscollector/

By sheer coincidence we have been discussing filtering bots from the
projectcounts files (at the source : webstatscollector) last week.
Not a new discussion, but with current resources this may be feasible now,
where it wasn't years ago.

Erik




-Original Message-
From: Lars Aronsson [mailto:l...@aronsson.se] 
Sent: Sunday, April 08, 2012 2:24 AM
To: Wikimedia developers
Cc: Erik Zachte
Subject: Page views

I'm telling people that the Swedish Wikipedia has 90-100 million page views
per month or on average ten per month per Swedish citizen. This is based on
stats.wikimedia.org (Wikistats), but is it really true? It would be really
embarrassing if it were wrong by some order of magnitude.

There is of course a difference between the language and the country.
Another measure says Internet users in Sweden (some 90 percent of all
citizens) make 16 page views to Wikipedia per month, including all
languages. Both numbers
10 or 16 make sense. But are they correct?

Wikistats also says Swedish Wikisource has 300-400 thousand page views per
month, which would be 10-13 thousand per day on average. Knowing how small
the Swedish Wikisource is (only
16,000 wiki pages + 37,000 facsimile pages), and comparing to other Swedish
language websites, I'm surprised that Swedish Wikisource could attract even
this much traffic.
Now we're at such a small scale, that reading through a day's logfile with
13,000 lines is realistic for a human.

Is there a chance WMF could publish the logfile for Swedish Wikisource for a
typical day, with just the IP addresses anonymized? Plus the source code
that counts the number of page views, by filtering out accesses from robot
crawlers and accesses to non-pages (like images and style sheets).

Page views for individual pages (on stats.grok.se) shows the Main page of
Swedish Wikisource is shown 120 times/day while Recent changes is shown 160
times/day. From my own experience, contributors are the only ones to look at
Recent changes, while they almost never look at the Main page. If IP
addresses are scrambled but not removed, the log file should be able to show
this pattern

[Wikitech-l] Skipping the review step for certain extensions

[Jeroen De Dauw]

Hey,

Most of my extensions have been migrated to the new git setup with gerrit.
I'm not happy with the workflow for the extensions where I'm basically the
only real contributor or those where no one is going to review my stuff
anyway. Although I can approve my own changes and merge them in, this is
rather silly. Is there a way to disable the review step for certain
extensions (ie post comit review instead of gated trunk), and is it
possible to automatically merge in commits of certain users? For example in
case of Semantic MediaWiki, I'd like my commits and those of the other core
SMW devs to be merged in without first needing a review, while commits of
random other people should require review first.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Upload of OpenDocument files safe?

[Platonides]

There's no check for the existance of macros.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] selenium browser testing proposal and prototype

[Platonides]

I wasn't able to make the selenium work (presumably selenium 1.0).
How hard would it be to make this work? Who would be responsible of
sorting out any problems encountered doing that and ensuring all
developers can locally run those tests?
(Actually, I'd try this before creating too many tests in that platform)

Say I've fixed a bug and want to add a test. How would I do it? In which
language? Do I need to know ruby for that?


Suppose there's a test:
* Failing in jenkins but passing locally.
OR
* Failing just for a single person.
OR
* Failing but it's apparently ok.
OR
* Passing but should be failing.

How do you debug it? Do you need to know ruby for that? To which extent?


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Upload of OpenDocument files safe?

[Chad]

On Sun, Apr 8, 2012 at 11:04 AM, Jean-Frédéric
 wrote:
> * If not, would you advise us to restrict this type of uploads to trusted
> users? [4]
>

Just a minor note on this point: we don't currently have any support
for per-group uploads. Ideally you would have some sort of array
with the key being the user right and the value(s) being the file
type(s) that you only want to allow for those users. This would leave
upload behavior unchanged for the rest of allowed filetypes.

-Chad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Upload of OpenDocument files safe?

[Jean-Frédéric]

Hi dear tech folks,

The MediaWiki 1.18 release notes stated the following:

“(bug 24230 [1]) Uploads of ZIP types, such as MS Office or OpenOffice can
now be safely enabled. A ZIP file reader was added which can scan a ZIP
file for potentially dangerous Java applets. This allows applets to be
blocked specifically, rather than all ZIP files being blocked.”

On the Wikimedia Commons village pump [2], concerns were still raised about
security (some referred to macros specifically).

Brion stated in 2008 that the ZIP issue was the only problem we had with
OpenDocument upload [3], and TheDJ confirmed so in said thread; but let’s
make it super-extra clear as for the technical side:

* Is it completely safe to enable upload of OpenDocument files on Wikimedia
Commons?
* If not, would you advise us to restrict this type of uploads to trusted
users? [4]

With this confirmation, we can quietly discuss on Commons whether we want
this or not :-)

Thanks for your help!

[1] 
[2] <
https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2012/03#Enabling_upload_of_ZIP_types.2C_such_as_MS_Office_or_OpenOffice
>
[3] <
http://lists.wikimedia.org/pipermail/wikitech-l/2008-November/040246.html>
[4] in the spirit of <
https://commons.wikimedia.org/wiki/Commons:Restricted_uploads>

-- 
Jean-Frédéric
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [pywikipedia r10097]: Revision status changed

[MediaWiki Mail]

"Xqt" changed the status of pywikipedia.r10097 to "deferred"
URL: http://www.mediawiki.org/wiki/Special:Code/pywikipedia/10097

Old status:  new
New status: deferred

Commit summary for pywikipedia.r10097:

update language_by_size from trunk r10094

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [pywikipedia r10094]: Revision status changed

[MediaWiki Mail]

"Xqt" changed the status of pywikipedia.r10094 to "deferred"
URL: http://www.mediawiki.org/wiki/Special:Code/pywikipedia/10094

Old status:  new
New status: deferred

Commit summary for pywikipedia.r10094:

update language_by_size

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Localisation commits status update

[Platonides]

On 26/03/12 11:25, Niklas Laxström wrote:
> * pretty formatting of core message files [BLOCKER]
> 
> Now the last issue is something I want your opinion on:
> Is it an issue if we drop pretty formatting of non-English message files?
> If it is an issue, I request your help to make the
> maintenance/language/rebuildLanguage.php script to support arbitrary
> location instead of just the current wiki installation. If it is not
> an issue, the first diffs will be big because of the change, but
> remaining ones will be small as usual.

What path would it need? mediawiki-install/languages/messages or just
the mediawiki root?
Seems quite easy to do. I don't know why you aren't using a single path,
though.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Daring to consider replacing gerrit (help write gareth)

[Daniel Friesen]

-- tl;dr start --
We're using gerrit now. And as we use it we all keep running into issues  
stemming fundamentally from how gerrit is designed.


I had an irc discussion with Roan[1] awhile ago tossing around ideas on  
how we would write a review system for git if we wrote one from scratch.
Based on a number of things I noted there I started a draft of how such a  
review system would work:

https://www.mediawiki.org/wiki/User:Dantman/CodeReviewSystem

I probably haven't written down nearly as much detail on that page as I've  
thought out for the actual system.


This is a long term project. It's definitely going to take awhile before  
it's ready to manage MediaWiki. However we're using git now, so this  
project doesn't have as much pressure. Since git is distributed things can  
easily coexist; We can put this up on labs before it's ready for  
primetime. When it's somewhat ready we can opt-in to trying it on less  
important repos. And even when we switch it will be possible to do so in a  
way such that gerrit and the review system co-exist until all changesets  
in gerrit have finished being reviewed.

-- tl;dr end --

In one of my one-day bouts of coding I started trying to implement the  
system:

https://github.com/dantman/gareth

Right now the code is EXTREMELY rough, and it barely does anything. My  
focus is on getting the fundamentals needed for the system to work  
(otherwise it's a fancy ui that does nothing). So I've made short-cuts on  
a lot of things so I don't get held back implementing the clean stuff.


I'm probably the only person with a whole enough idea of how this'll work  
to push forward on the fundamental parts of it.
However despite that I welcome help on the project and have a number of  
things that other people should still be able to write while I work on the  
fundamental pieces.


Right now I've skipped past a number of things:
- We need a views system, something that will let us template out many  
sections of html. And will allow different themes to override them.
- Right now I've copied some of the classes from MediaWiki like WebRequest  
and stripped stuff out of them. Anyone up to it is free to clean these up  
into the start of a real framework based on MW's code that can in the  
future be the base of both this and MW.
- The project needs a good database system. I copied our database classes  
in but never got to using them. I'm isolating all database stuff into some  
model classes so different database handing can be swapped in. Anyone who  
feels up to it can adapt our database code to work as a framework for the  
review system.
- Right now I'm implementing git handling using proc_open to interact with  
git's porcelain and plumbing commands. Anyone who feels up to the task is  
free to implement a PHP extension for interfacing with git we can swap  
over to using.
- I'd really like to eventually have a way to list a set of commits using  
a nice line graph the way that things like gitk, gitx, and source tree  
too. I welcome anyone who feels like trying to write something like a JS  
library to generate in-page SVG (Raphael?) making a vertical list of  
commits listed that way.


I welcome anyone who feels like turning the short-cuts into a properly  
written system. And anyone who feels like turning MediaWiki's code into a  
framework. Or anyone who feels that a framework they know fits best and  
wants to make the review system use it (Though no file layout controlling  
MVC frameworks, please).


[1]: The discussion was buried somewhere deep in  
http://bots.wmflabs.org/~petrb/logs/%23mediawiki/20120329.txt try  
somewhere around [20:16:09]

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Git/gerrit and RELEASE-NOTES-1.20 merge conflicts

[Harry Burt]

On 05/04/12 10:53, Daniel Friesen wrote:
> I thought this might be problematic to have everyone install. But
> thinking about it again. Gerrit is the one doing merges. If that can
> handle the RELEASE-NOTES format that we uses. Then theoretically
> installing it on the server gerrit uses and then configuring our release
> notes to use it could theoretically make Gerrit suddenly able to handle
> RELEASE-NOTES changes without conflicts.

Could we also make sure that Jenkins is upgraded with this functionality?

e.g. for when Jenkins tests patchset n, where n > 1.

Harry (User:Jarry1250)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GSoC -- TranslateSvg: Bringing the translation revolution to Wikimedia Commons

[Harry Burt]

Hey all,

thanks for your replies. Unfortunately I wasn't able to read them until
today, so the "official" GSoC proposal has now been sent off. That said,
I'm no less enthusiastic about reaching out to knowledgeable people
involved with translation, and, if necessary, adapting the way GSoC works
out (if my proposal is accepted) or the future roadmap for TranslateSvg
generally (if it is not).

So yes, comments still very much welcome :) I also have a few thoughts on
what has been said already, and I'm hoping this can open up a dialogue
(either on this list or bilaterally).

Firstly, image "translation" isn't just (string) translation, which (as I
understand it), is what the Translate extension focuses on. For example, it
will involve users adjusting co-ordinates to ensure the image displays
properly. It will involve changing formatting, including font size, and
possibly bolding as well. It may even end up involving the selection of
typefaces too. It will definitely involve an image preview. Is the
architecture of the extension sufficiently high-level to accommodate these
on a per-language basis, I wonder? If it is, then building on top of it
sounds like a real possibility.

Secondly, to respond to the question over Translatewiki.net, it is worth
noting that the extraction and input of translatable strings into SVGs is
non-trivial. If you imagine these as being hosted on Wikimedia Commons, a
workflow taking in TranslateWiki.net would have, I think, to involve an
intermediary storage area which TranslateWiki.net saves into, then a
Wikipedia bot processing those, generating the new files and then uploading
then daily/weekly onto Commons. That storage area would have to be
populated by a second process. It's certainly doable, but it's tricky.
Let's remember that there are 534,644 SVG files on Commons, suggesting that
as many as 100,000 could end up being run through this process. Now,
obviously, if we end up with 100,000s of new file versions uploaded, we are
simply victims of our own success: but unlike interface translation it's
not clear that even 1% of those updates will ever do any good at all -
there's no known use case already in place. One solution could be to only
pass SVGs being displayed in the "wrong" language on a wiki onto
Translatewiki.net but, I'm keen that image translation be possible with
immediacy. Although the lag-based process is neat, I would like casual
users to be able to translate on-the-spot and with immediate effect, e.g.
when they go to reuse a not-yet-translated SVG on their home wiki, without
necessitating registration on Translatewiki.net and/or some kind of
processing lag. There's probably a strong case for having *both* a local
translation page - for casual users - *and* a Translatewiki.net process to
allow for power translation. However, I would argue that the former is more
important than the latter.

To answer Gerard's query, I never intended the prototype to be properly
reviewed, but it did generate an amount of attention and certainly
fulfilled its role as a proof of concept.

Regards,
Harry (User:Jarry1250)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GSOC 2012 : Lucene Automatic Query Expansion From Wikipedia Text

[Robert Stojnic]

Hello,

Yep, generating the wodnet itself is a challenging and interesting 
project. I was simply commenting on the Lucene part, i.e. on possible 
application.


Currently the lucene backend works by employing some very general rules 
(e.g. titles get highest score, then first sentence in articled, then 
first paragraph, then words occurring in clusters e.g. within ~20 words, 
etc..). However, in many cases they fail.


I found it helpful to run a number of queries and then see when/why the 
search fails to identify the most relevant article. When wordnet is 
mentioned, two examples come in mind which are both currently unsolved. 
One is a query of type "mao last name" where an article "mao (surname)". 
If we are lucky, the article will have words "last name" somewhere in 
the article and the search won't totally fail, however, it would be nice 
if the algorithm knew that "last name" == "surname". Another is when the 
query is of type "population of africa" and the article "African 
population". That is, it would be helpful if the backend knew of 
language constructs like "x of y" == "x-an y". I wonder if Wordnet type 
of approach can find those cases as well.


Cheers, Robert


On 06/04/12 17:54, Oren Bochman wrote:

Hi Robert Stojnic and Gautham Shankar

I wanted to let Gautham that he has written a great proposal and thank you
for the feedback as well.

I wanted to point out that in my point of view the main goal of this
multilingual wordnet isn't queary expansion, but rather means for ever
greater cross language capabilites in search and content analytics. A
wordnet seme can be  further disambiguated using a topic map algorithm run
which would consider all the contexts like you suggest. But this is planned
latter and so the wordnet would be a milestone.
To further clarify Gautham's integration will place a XrossLanguage-seme
Word Net tokens during indexing for words it recognises - allow the ranking
algorithm to use knowldege drawn from all the wikipedia articles.
(For example one part of the ranking would peek into featured article in
German on "A" rank it>>  then "B" featured in Hungarian and use them as
oracles to rank A>>  B>>  ... in English where the picture might now be X

Y>>  Z>>  ... B>>  A ...)

I mention in passing that I have began to develop dataset for use with open
relavance to sytematicly review and evaluate dramatic changes to relevance
due to changes in the search engine. I will post on this in due course as
it matures - since I am working on a number of smaller projects i'd like to
demo at WikiMania.)

On Fri, Apr 6, 2012 at 6:01 PM, Gautham Shankar<
gautham.shan...@hiveusers.com>  wrote:


Robert Stojnic  gmail.com>  writes:



Hi Gautham,

I think mining wiktionary is an interesting project. However, about the
more practical Lucene part: at some point I tried using wordnet to
expand queries however I found that it introduces too many false
positives. The most challenging part I think it *context-based*
expansion. I.e. a simple synonym-based expansion is of no use because it
introduces too many meanings that the user didn't quite have in mind.
However, if we could somehow use the words in the query to find a
meaning from a set of possible meanings that could be really helpful.

You can look into existing lucene-search source to see how I used
wordnet. I think in the end I ended up using it only for very obvious
stuff (e.g. 11 = eleven, UK = United Kingdom, etc..).

Cheers, r.

On 06/04/12 01:58, Gautham Shankar wrote:

Hello,

Based on the feedback i received i have updated my proposal page.

https://www.mediawiki.org/wiki/User:Gautham_shankar/Gsoc

There is about 20 Hrs for the deadline and any final feedback would be
useful.
I have also submitted the proposal at the GSOC page.

Regards,
Gautham Shankar
___
Wikitech-l mailing list
Wikitech-l  lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Hi Robert,

Thank you for your feedback.
Like you pointed out, query expansion using the wordnet data directly,
reduces
the quality of the search.

I found this research paper very interesting.
www.sftw.umac.mo/~fstzgg/dexa2005.pdf
They have built a TSN (Term Semantic Network) for the given query based on
the
usage of words in the documents. The expansion words obtained from the
wordnet
are then filtered out based on the TSN data.

I did not add this detail to my proposal since i thought it deals more
with the
creation of the wordnet. I would love to implement the TSN concept once the
wordnet is complete.

Regards,
Gautham Shankar



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Hi again




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GSoC: Caterpillar the Category Tool

[Maarten Dammers]

HI Kalan,

You might want to read 
https://commons.wikimedia.org/wiki/User:Multichill/Next_generation_categories


Maarten

Op 6-4-2012 17:11, Kalan schreef:

Hello,

I present a proposal for a system that is going to solve the category
intersection problem (and, in fact, allow all set-theory operations
for categories). The name I suggest for it is “Caterpillar”.

Such a system would consist of a C or C++ backend daemon that stores
all the category graph in RAM and MediaWiki extension frontend.

Here is the full text of the proposal:
https://www.mediawiki.org/wiki/User:Kalan/gsoc

I am seeking for an interested mentor.

— Kalan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l