Wikitech-l March 2012

wikitech-l@lists.wikimedia.org

155 participants
204 discussions

Students: apply for GSoC between now and April 6th
by Sumana Harihareswara 26 Mar '12

26 Mar '12

If you want to participate in Google Summer of Code, you must submit an application via http://www.google-melange.com/ before April 6, 19:00 UTC. google-melange.com is now open and accepting applications. "Wikimedia Foundation" is the organization you're submitting an application to. -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

1 0

PHPUnit and table visibility
by Christian Aistleitner 26 Mar '12

26 Mar '12

Dear everyone, our current PHPUnit setup uses temporary tables for MySQL; tables that are visible only to the current connection. When trying to test core objects (e.g.: BackupDumper) that spawn a separate database connection, this causes trouble, as this new database connection does not see the temporary tables of the first connection. How to test such objects? Possible ways around might be to (i) modify the tested object, (ii) modify the PHPUnit setup, (iii) force a special load balancer for testing, or (iv) completely mock the database for tests (when testing non backend objects). Any suggestions / preferences? Kind regards, Christian P.S.: As this might affect the discussion: A different incarnation of the same problem is that our PHPUnit test suite currently does not run on a MySQL cluster (without passing --use-normal-tables). -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian(a)quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ ---------------------------------------------------------------

1 0

Cloning all the git migrated projects
by Platonides 26 Mar '12

26 Mar '12

As we have now lots of repositories: https://gerrit.wikimedia.org/r/#admin,projects I'm sharing a nifty script to clone them all at once. http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/code-utils/clone-all.… (edit $skipRepositories at the top to ignore another set, such as integration/*)

3 3

Wikipedia Url Shortner Service
by Andrea Stagi 26 Mar '12

26 Mar '12

Hi all, working on Wikipedia mobile app I realized that urls we want to share are too long sometimes and this is a problem when your maximum number of characters is limited. I think that Wikipedia should provide an own shortner url service, like goo.gl, bit.ly etc.. There's just an unofficial service for English Wikipedia: enwp.org... Petan on IRC proposed something like this: wm.org/language/Article for example wm.org/en/Prague Ok, wm.org is not free actually, but we can think about something similar... What do you think? Regards, =.4.S.= -- =.4ndrea.Stagi.=

14 21

Re: [Wikitech-l] [Wikitext-l] Fwd: Cutting MediaWiki loose from wikitext
by Jeremy Baron 26 Mar '12

26 Mar '12

On Mon, Mar 26, 2012 at 12:50, Maximilian Doerr <cybernet678(a)yahoo.com> wrote: > I strongly disagree with removing wiki text. Several thousand bots depend > on it. Especially Cluebot NG which is a highly sophisticated anti-vandalism > bot. I recommend going our current route where the visual editor writes the > Wikimarkup realtime and vice versa. I suspect maybe you didn't understand Daniel's message? (or didn't read it?) I imagine most pages will still use the same markup we have today after his idea is implemented. For the pages that are different, the bots can and should adapt. -Jeremy

1 0

Dropping support for the automatic /index.php/Article
by Daniel Friesen 26 Mar '12

26 Mar '12

For awhile we've supported automatic detection guessing if the webserver supports PATH_INFO and if so automatically using /index.php/$1 for the article path. I believe this even predates our better REQUEST_URI handling. I'm considering the idea of dropping support for this automatic setup. There are a few faults to this feature we have. Firstly there are cases where it may break. And I don't mean simple graceful breakage. I mean it is possible for us to detect support incorrectly on a slightly misconfigured webserver setup and when that happens we outputs a fatal page telling the user they have to add some config to their LocalSettings.php in order to get their wiki to even work. So you can end up installing MediaWiki, following the "enter your wiki" link, and end up on a big white plaintext page telling you your wiki was broken from the start. It can also cause problems when you change hosting. We detect this automatically based on whether the current server supports it. This isn't like short urls where the user sets up the configuration and practically every single server that exists will support configuring it. In this case because we auto-detect it if you move from a server setup that supports /index.php/Foo and then move to something using say FastCGI where it doesn't work by default all of a sudden your urls change. And not just change, every url that people have bookmarked becomes invalid. And of course it creates a bit of a negative incentive. Because /index.php/Foo is so simple and works out of the box people lazily don't bother to setup proper short urls. The short url they have is only slightly shorter. It 'still' is hardwired to architectural facts like the filesystem and the fact we're using .php. ---- So I'm considering dropping this automatic feature. Making this change will mean that MediaWiki will start outputting /index.php?title=... style URLs for everyone who hasn't configured short urls. A few important notes: - This will NOT break existing wikis. We may still leave the actual fallback PATH_INFO detection in place. And REQUEST_URI will always keep the implied /index.php/$1 inside the PathRouter. So even though we won't be outputting /index.php/Foo style urls if the wiki previously supported /index.php/Foo all those urls will still point to the pages. The links we output will just start using ?title=. - While we won't be doing anything automatic anymore anyone obsessed with having /index.php/Foo can still simply set `$wgArticlePath = "/index.php/$1";` if it works on their server. ---- What are peoples thoughts on this plan? -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

5 9

git source code links
by Thomas Gries 26 Mar '12

26 Mar '12

I added links to the source code (git) - extension download template ( https://www.mediawiki.org/wiki/Template:WikimediaDownload ) - rendered as part of the Exteninsion info box - https://www.mediawiki.org/wiki/Download_from_Git#Download

3 5

Integrating "who's been awesome?" to MedaiWiki
by Eranga Mapa 26 Mar '12

26 Mar '12

Hi Sumanah Did you recieved the mail I sent to u regarding my extension to synchronize video with other content? By the way I am hoping to hear soon from James regarding Integrating "who's been awesome?" to MediaWiki. Thanks Undergraduate Computer Science and Engineering University of Moratuwa Student Member IEEE

3 6

Bugzilla Weekly Report
by reporter 26 Mar '12

26 Mar '12

MediaWiki Bugzilla Report for March 19, 2012 - March 26, 2012 Status changes this week Bugs NEW : 246 Bugs ASSIGNED : 12 Bugs REOPENED : 36 Bugs RESOLVED : 132 Total bugs still open: 7392 Resolutions for the week: Bugs marked FIXED : 81 Bugs marked REMIND : 0 Bugs marked INVALID : 22 Bugs marked DUPLICATE : 11 Bugs marked WONTFIX : 13 Bugs marked WORKSFORME : 5 Bugs marked LATER : 2 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component ArticleFeedbackv5 17 Git/Gerrit 11 Vector skin 7 Special pages 4 Semantic MediaWiki 4 New Bugs Per Product MediaWiki 34 Wikimedia 21 MediaWiki extensions 44 Security 2 Wikimedia Tools 2 Top 5 Bug Resolvers sam [AT] reedyboy.net 22 mah [AT] everybody.org 10 santhosh.thottingal [AT] gmail.com 7 EN.WP.ST47 [AT] gmail.com 7 amir.aharoni [AT] mail.huji.ac.il 6

1 0

consecutive commits in Gerrit
by Amir E. Aharoni 26 Mar '12

26 Mar '12

Hi, There's something in Gerrit that i still don't get, even after trying to ask this several times on mediawiki.org [1] and on IRC. I sincerely thank everyone who took the time to reply, but either i still misunderstand the replies or i do understand them and I Just Don't Like It [2]. Let's consider a patch set i submitted: https://gerrit.wikimedia.org/r/#change,3361 . The patch set as i submitted it was not perfect and Aaron marked it "-1". So far, so good. Then Hashar amended the patch set and Nikerabbit amended it some more. Now here's what i don't like: The diffs of their changes show all the changes instead of just showing Hashar's and Nikerabbit's changes. This is somewhat similar to how we review patches by new volunteer developers - if the patch attached to a Bugzilla is not perfect we ask to write a whole new one. That's the custom, and maybe it's considered educational, but actually its usefulness is doubtful. Despite this, it is now applied to all the commits. Now honestly, the result in the story of this particular patch set is OK. The resulting patch is better than the first one and the collaboration worked well. But does this scale? This patch set changes only a few lines of code; what will happen with patch sets in which dozens of lines are changed? These happen very often. The reviewer will have to re-read all the changed lines for every amend and this looks like a huge waste of time. It would make a lot more sense to me to see these three changes as a branch with three commits - the first one is mine, the second one is Hashar's fix and the third one is Nikerabbit's fix. When there's agreement that the tip of the branch is good, it's merged to the master branch. If a reviewer wants to see the whole end-to-end diff, it's not hard. Mind you, this has nothing to do with SVN - in SVN branches are used rarely. This, to the best of my understanding, is the Git way. Git makes this sensible scenario easy, and it is used successfully in Github - but in the Gerrit workflow this scenario is not used. I tried reading the Gerrit manual [3] and it didn't make it any clearer. Yet again, i may be misunderstanding something, so correct me if i'm wrong; It's really weird that a tool that makes code review so central makes it a lot harder, too. But that's the feeling that i get. Am i just wrong in my understanding of Gerrit? Am i the only one who doesn't like it? Is it too late to complain? [1] https://www.mediawiki.org/wiki/Talk:Git/Workflow [2] As in https://en.wikipedia.org/wiki/Wikipedia:IDONTLIKEIT . [3] http://gerrit-documentation.googlecode.com/svn/Documentation/2.2.2/index.ht… -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

2 4

← Newer
1
...
4
5
6
7
8
9
10
...
21
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 March 2012