Wikitech-l November 2011

wikitech-l@lists.wikimedia.org

127 participants
144 discussions

Coding Convention: Method chaining
by John Du Hart 17 Nov '11

17 Nov '11

Right now our coding conventions manual never touches on method chaining, nor have I personally seen this practice in core. So I'm interested in what the rest of the community feels about adapting this practice more, and if there are trade offs I'm not aware of. Let's make an example, take this code from Abuse Filter: $out = $this->getOutput(); $out->setPageTitle( wfMsg( 'abusefilter-examine' ) ); $out->addWikiMsg( 'abusefilter-examine-intro' ); So, instead of writing it like that, it could be written $this->getOutput() ->setPageTitle( wfMsg( 'abusefilter-examine' ) ) ->addWikiMsg( 'abusefilter-examine-intro' ); It's just another style I've encountered on other projects and I personally like. -- John Du Hart

12 13

HTTPS-Everywhere
by Raimond Spekking 17 Nov '11

17 Nov '11

Hi, it seems, that the latest stable version of HTTPS-Everywhere 1.2.1 fully supports the new HTTPS structure of Wikimedia wikis \o/ Raimond.

3 3

Fwd: Old English Wikipedia image dump from 2005
by emijrp 16 Nov '11

16 Nov '11

Forwarding... ---------- Forwarded message ---------- From: emijrp <emijrp(a)gmail.com> Date: 2011/11/11 Subject: Old English Wikipedia image dump from 2005 To: wikiteam-discuss(a)googlegroups.com Hi all; I want to share with you this Archive Team link[1]. It is an old English Wikipedia image dump from 2005. One of the last ones, probably, before Wikimedia Foundation stopped publishing image dumps. Enjoy. Regards, emijrp [1] http://www.archive.org/details/wikimedia-image-dump-2005-11

2 1

page view stats redux
by Ariel T. Glenn 16 Nov '11

16 Nov '11

I think we finally have a complete copy from December 2007 through August 2011 of the pageview stats scrounged from various sources, now available on our dumps server. See http://dumps.wikimedia.org/other/pagecounts-raw/ Ariel

9 16

Making developer access easier to get
by Yaron Koren 16 Nov '11

16 Nov '11

Hi, I think developer accounts on the Wikimedia SVN repository should be easier to get. I say this because a consultant of ours at WikiWorks, Ike Hecht, asked for a developer account last week and was rejected. He created his first major MediaWiki extension, Ad Manager, recently, which I added to the repository a few weeks ago - you can see it here: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/AdManager/ When he requested access, this was the relevant part of the response from Sumana: "Right now, we are not approving your request for commit access. I'm sorry. We'd like for you to get more practice writing code for MediaWiki, submit patches for review via Bugzilla attachments, and ask us for comments... Please come back and request access again in a few months." I don't know whether this is WMF policy now, or a personal decision from Sumana, or a decision made by someone else, but in any case I don't understand it. It seems to me that there are two valid reasons for not simply allowing everyone to get a developer account: the first, and major, reason is to prevent malicious users from vandalizing or deleting code. The second is to prevent well-intentioned but incompetent developers from checking in buggy and/or badly-written code that requires lots of fixes and review time by the reviewers. In both cases, the person's presence in SVN would cause more harm than good. Neither of those cases apply here - the Ad Manager code was well-written, and it works. If you're curious, you can see for yourself the kinds of fixes and changes that were made to the code after it was checked in - all minor stuff, the only major thing being that the extension originally included support for MediaWiki 1.15, which people thought was unnecessary. Clearly a higher bar is being applied here than what's spelled out in the mediawiki.org documentation - which only says that "we don't have time to train programmers from scratch": http://www.mediawiki.org/wiki/Commit_access#Prerequisites Note, by the way, that if there's a more stringent policy in place now, it's not being applied consistently, because the students in this year's Google Summer of Code got developer access after much less proof of programming ability. It seems to me that if someone writes an extension that basically matches the MediaWiki guidelines, works, and does something useful, they should pretty much be granted automatic access to an account, because they will have proved that their presence will be a net positive overall. Any thoughts on this? And out of curiosity - is there a new policy in place? -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com

12 26

New committer
by Sumana Harihareswara 16 Nov '11

16 Nov '11

Just granted extensions access to Remco de Boer as remco (User:Rcdeboer on mediawiki.org) to work on various extensions, especially those in the semantic bundle. Welcome! -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

1 0

This week: Patch Review and Upload Wizard Triage
by mhershberger＠wikimedia.org 16 Nov '11

16 Nov '11

What: Weekly Patch Review When: Wednesday, Nov 16, 2130UTC Time zone conversion: http://hexm.de/a6 Where: #wikimedia-dev on freenode Use http://webchat.freenode.net/?channels=wikimedia-dev if you don't have an IRC client To keep the patch queue down to a reasonable level, I'm going to start weekly patch review session. The first one of these will be tomorrow and, if everything goes well, we'll probably end up doing this weekly. What: UploadWizard Triage When: Thursday, Nov 17, 2130UTC Time zone conversion: http://hexm.de/a7 Where: #wikimedia-dev on freenode Use http://webchat.freenode.net/?channels=wikimedia-dev if you don't have an IRC client Sumana and I were discussing what to focus the triage on this week and, after a bit of poking at Bugzilla, we decided that UploadWizard would make a good candidate. Hope to see you at one or both of these! Mark.

1 0

en-CA in MediaWiki? Rethinking our method of handling translation bugs?
by Daniel Friesen 15 Nov '11

15 Nov '11

A few months ago I opened a bug asking for en-CA support in MediaWiki: https://bugzilla.wikimedia.org/show_bug.cgi?id=31016 For reference en-CA is neither strictly en-US or en-GB. en-CA uses some spellings en-GB use and in other cases some spellings that en-US use, and there are a slight few en-CA specifics as well. Examples of the differences: en-CA and en-GB uses 'colour' while en-US uses 'color'; en-CA and en-US use 'Uncategorized' while en-GB may use 'Uncategorised'; en-US and en-CA use 'program' while en-GB use 'programme'; And I believe the CA/GB/AU grammar idiom where 'the' may end up omitted on some cases applies to 'in process of' instead of en-US' 'in the process of'. Extension wise; We use "Expiry date" rather than "Expiration date", I'm not sure what en-GB uses other than "Use by" but "Expiry" seams to be en-CA specific. Moving on. That bug was closed as INVALID and I was told I could start translating the language at translatewiki. I signed up at TWN and asked for translation permissions. A day or so later I got them and started translating en-CA. After finishing translating en-CA for MediaWiki and being halted part way through translating extensions after realizing that one extension had several hundred messages that were almost entirely the same and I had to translate a single word in all of them... Siebrand deleted every en-CA translation from TWN with the comment "en-ca not needed in MediaWiki". https://translatewiki.net/w/i.php?title=Special%3ALog&type=delete&user=SieB… I've poked Siebrand about en-CA on his talkpage, and several times in irc when he's recently been active. But it seams he's simply ignoring what I say about en-CA. I would like to get en-CA support into MediaWiki though it looks like that's been shot dead in the water. I'm noticing a related trend lately in regards to TWN: https://bugzilla.wikimedia.org/show_bug.cgi?id=31229 https://bugzilla.wikimedia.org/show_bug.cgi?id=32264 Whenever someone reports a bug asking for a translation change, we seem to mark it as INVALID, and then tell the reporter to go to translatewiki, go through the process of getting translator permission, and then translate it themselves. To me that's like marking a bug with a patch as INVALID and saying that the reporter should get svn commit access and commit it themselves Rather than closing bugs as INVALID and shoving off people reporting bugs to another site IMHO when we see a translation bug we should try to fix it inside the translation, mark the bug as FIXED, and remind the reporter that if they have more translations to be fixed they should sign up at TWN and help out with the translations. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

11 18

Another SVN error? (was: Re: [Ticket#2011091710005702] SVN Extension Access)
by Huib Laurens 15 Nov '11

15 Nov '11

I have to say that I have the same expirance with the current process for requesting commit access. I currently have access to SVN, it was given to me 2 years ago by TimStarling. But i changed my key(s) but it didn't change for Wikimedia. So I requested Sumana to close my old account and give me a new account with a better name. This was her responds: Hi Huib, I apologize for the late response. After some discussion, we decided that the best way to proceed is for you to submit your proposed improvements as a patch in bugzilla.wikimedia.org, or make your extension public on mediawiki.org (http://www.mediawiki.org/wiki/Category:Extensions). This gives us a much better idea of what your proposal is and makes it a lot easier to review. Sincerely, Priyanka Dhanda So I was already given access, but by error I lost the key and now got removed. I don't really think the current proces is helping to get more volunteers... Best, Huib Laurens 2011/11/5 Neil Kandalgaonkar <neilk(a)wikimedia.org> > Olivier, I'm truly sorry you had such a negative experience. This is not > an acceptable situation. We have an inconsistent process, and one which > is a bit heavyweight when our resourcing for it is rather lightweight. > > I wish you had found the patience to assume good faith. There is no > reason for accusations that we don't want good developers. Of course we > *want* them. If we are failing to act like it, it wasn't a personal slam > at you. > > And, if I may be forgiven for white-knighting, Sumana's job is to needle > the rest of us so we don't forget about concerns like yours and she > generally does it very well. And she did sound an apologetic note into > the email she sent you. So IMO she's not the problem here. Why she > played a game of telephone here is a bit of a mystery to me though -- > maybe she just wanted to be sure that *someone* pinged you since it had > been so long. IMO the developer who reviewed your code should have > contacted you directly. > > I had a look at the module you wrote. I share some of the same concerns > about scalability, but that's not really the issue. > > I have some experience with user-contributed module archives, having > administered some shared community resources for Perl, Python, and so > on. The cultural differences and relative successes were interesting. > The Python people wanted to have a review process, and a GUI interface, > and binary modules precompiled, and so on and so on, and their projects > never really got off the ground. Perl's CPAN started off as a simple FTP > site where almost anyone could upload code. Guess which one ultimately > succeeded. The point is, IMO there's relatively little payoff for having > *any* review process for modules. Just have a way to report and remove > malware and be done with it. As long as it's clear that the Foundation > doesn't endorse the software there, what is the problem? Maybe we can > also have some kind of badge for "reviewed" or "as seen on Wikipedia" > for the stuff we consider good enough to deploy on big sites. > > We already more or less do this -- for instance, there are modules by > GSoC students that are clearly not ready for prime time, and they are > marked accordingly. > > > > On 11/4/11 11:47 PM, MZMcBride wrote: > > > The long and short of my advice is this: fuck MediaWiki. If they're > > unwilling to accept your contributions, there are a lot of other FOSS > > projects that would be happy to have you. Thrilled to have you, even. I'd > > strongly encourage finding one. :-) > > And why should he listen to you, when you are unwilling to follow your > own advice? > > -- > Neil Kandalgaonkar |) <neilk(a)wikimedia.org> > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Kind regards, Huib Laurens WickedWay.nl Webhosting the wicked way.

7 6

Re: [Wikitech-l] 1.18 PHP version requirement
by Roy Bellingan 15 Nov '11

15 Nov '11

Sorry I don't understand, a lot of people are complaining about their distro not shipping "late" version, not latest... I perfectly understand, i've a server with a CentOs frozen in time somewhere in 2007... and I'm SCARED to touch anything... It run and old version of mysql, kernel 2.18.something, old Perl... but it runs... and does the job without any problems... In short I will never think to install nothing except a munin plugin... The point is: are you using an extra stable distro, with extra tested software and do you want to INSTALL a bleeding edge ? -- Roy Bellingan admin(a)tsmt.eu CG & ArchiVIZ *http://archidea.us* Programmazione & SysAdmin *http://tsmt.eu*

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
15
Older →

Jump to page:

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