Wikitech-l February 2013

wikitech-l@lists.wikimedia.org

161 participants
171 discussions

Mediawiki's access points and mw-config
by Waldir Pimenta 12 Mar '13

12 Mar '13

While trying to add some more information to https://www.mediawiki.org/wiki/Manual:Code, I came across a slightly peculiar issue regarding the entry points for MediaWiki: Right now, among all the entry points that I know of (those are listed in Manual:Code), only mw-config/index.php doesn't sit in the root folder. Furthermore, it's related to the installer at includes/installer/, but that is not clear at all from the code organization, specifically the directory names (and the lack of documentation both in the file and on mediawiki.org). I have two questions, then: 1) should all access points be on the root directory of the wiki, for consistency? 2) should the name "mw-config" be changed to something that more clearly indicates its relationship with the installer? Note that these aren't merely nitpicking: a consistent structure and intuitive names for files and directories play an important role in the self-documenting nature of the code, and make the learning curve smoother for new developers (e.g. yours truly :-)). Also, I used Tim Starling's suggestion on IRC to make sure the list of entry point scripts listed in Manual:Code was complete: git grep -l /includes/WebStart.php I am not sure that exhausts the list, however, since thumb_handler.php doesn't show up on its results. Any pointers regarding potential entry points currently omitted from that list are most welcome. --Waldir ps - while investigating this subject I came accross some inconsistencies in the way the access points include the WebStart.php file, including an incorrect use (according to Tim) of require_once() instead of require(). I submitted a change to Gerrit harmonizing them; if this interests you, please review the commit: https://gerrit.wikimedia.org/r/#/c/49208/

6 16

RFC: image information API
by Max Semenik 11 Mar '13

11 Mar '13

Hi, over the time the questions like "how do I determine programmatically the license of this image?" or "who is the author of that video? no, uploader's username is not enough" are asked quite regularly, and probably now it's time to fix this. Please take a look here: https://www.mediawiki.org/wiki/Requests_for_comment/Image_information On that page, I'm trying to collect the requirements for extension that would address these problems, as well as the ways of implementation. If all goes well, I'd like to start coding in 1-2 weeks. -- Best regards, Max Semenik ([[User:MaxSem]])

7 6

Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
by Greg Grossmeier 11 Mar '13

11 Mar '13

(apologies for the none-theading of this; I wasn't subscribed to wikitech-l with this address when this message/thread was sent) <quote name="Mark A. Hershberger" date="2013-02-19" time="23:09:18"> > On Tue 19 Feb 2013 04:39:25 PM EST, Sumana Harihareswara wrote: > >> My longer term question is: Who is MediaWiki's release manager, and > >> what > >> can we expect of the person who has that role? > > > > I think the answer is now that Greg Grossmeier fills the role of > > MediaWiki's release manager so he will have to answer this. :-) > > This subject has come up a couple of times in the past week so I look > forward to working with Greg to implement some policy around MediaWiki > releases -- especially the point releases for 1.19, the LTS release. > There is a lot to discuss and I look forward to those conversations. Hello! To make this explicit: Everyone: please do feel free to contact me (email or on IRC, I'm greg-g) with any ideas, concerns, breakthroughs, gotchas, whatever dealing with this topic. I might not be able to do anything about it now, and I might not be the right person to deal with it in all cases, but I can help route things and keep notes so that we don't lose track of good ideas. Generally, what can you expect from me in this new role? I hope the email robla sent announcing my position can clarify much of it: http://lists.wikimedia.org/pipermail/wikitech-l/2013-February/066672.html Quoting robla: > Greg will be managing the deployment process for the Wikimedia > websites, focusing at first on improving release notes and outbound > communication, freeing up folks like Sam to focus the engineering > aspects of the role. He'll help our Bug Wrangler (Andre) figure out > how to deal with high priority deployment-related issues; Andre will > continue to broadly manage the flow of all bugs, while Greg will > narrowly focus on very high priority issues through fix deployment. > He'll also take over coordination of our deployment calendar[1], and > will likely be a little nosier than many of us have had the time to > do. Over time, Greg will look more holistically at our deployment > practice, and potentially lead a change over to a more continuous > deployment model. Best, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | [[User:Greg G (WMF)]] A18D 1138 8E47 FAC8 1C7D |

22 39

Bug 1542 - Log spam blacklist hits
by anubhav agarwal 11 Mar '13

11 Mar '13

Hi Guys, I was trying to fix this<https://bugzilla.wikimedia.org/show_bug.cgi?id=1542>bug. I am a newbie to mediawiki and it's a first bug I'm trying to solve, so I don't know much. I want to know about the spam block list, how does it works, how does trigger the action, and its logging mechanism. It would be great if some one could help me fix this bug. Cheers, Anubhav Anubhav Agarwal| 4rth Year | Computer Science & Engineering | IIT Roorkee

5 10

Bugzilla Weekly Report
by reporter 06 Mar '13

06 Mar '13

MediaWiki Bugzilla Report for December 31, 2012 - January 07, 2013 Status changes this week Bugs NEW : 520 Bugs ASSIGNED : 58 Bugs REOPENED : 39 Bugs RESOLVED : 177 Total bugs still open: 9050 Resolutions for the week: Bugs marked FIXED : 125 Bugs marked REMIND : 0 Bugs marked INVALID : 16 Bugs marked DUPLICATE : 15 Bugs marked WONTFIX : 9 Bugs marked WORKSFORME : 17 Bugs marked LATER : 0 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component General/Unknown 9 Special pages 7 General/Unknown 6 GuidedTour 4 General 3 New Bugs Per Product MediaWiki 31 Wikimedia 21 MediaWiki extensions 45 Datasets 1 Security 1 Top 5 Bug Resolvers aklapper [AT] wikimedia.org 23 jrobson [AT] wikimedia.org 13 krenair [AT] gmail.com 8 s.mazeland [AT] xs4all.nl 8 krinklemail [AT] gmail.com 7

9 11

Problem with CentralAuth in MobileFrontend
by Juliusz Gonera 05 Mar '13

05 Mar '13

Hi, Yesterday we released photo uploads in mobile (actually moved it from beta to stable). We're logging errors we get when people try to upload photos and it seems the most common one is that they're not logged in to Commons even though they logged in to Wikipedia. It seems to be happening quite randomly and doesn't seem to depend on any particular browser. We're not sure how to debug this. Have any similar issues ever happened on desktop (people not being logged in to other projects)? Is there anyone who has a good knowledge of how CentralAuth works and could help us? Thanks, Juliusz

7 11

Subclassing HTMLForm Question
by Tyler Romeo 04 Mar '13

04 Mar '13

Hey, So there's a change (https://gerrit.wikimedia.org/r/48995) that's adding a new subclass to HTMLForm, so I had a quick question for whoever has more experience with HTMLForm than I do. The new subclass will always output a table for the getInputHTML(), even if the parent form is set to div/raw output. Is this OK, i.e., is the table/div/raw only applicable to the form itself, or should the subclass make sure to follow that format as well? Unfortunately, there is no precedent for this because every other field type only puts out an input tag. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

4 5

Release policy
by Mark A. Hershberger 02 Mar '13

02 Mar '13

After the discussion last week, I want to scope out a release policy so that we'll all know what to expect. * A major release will be made every six months. * An LTS release will be made every two years. There will be a one-year overlap in LTS support. For example, 1.19 is supported until May 2015. 1.23 will be released the year before that so that people will have 1.23 available as an LTS to move to and a year to make the transition. * Releases notes will continue to be the basis for seeing what has changed. Because of the nature of a volunteer-driven project, it isn't possible to say with any certainty what *will* happen in the next 6-12 months. * To mitigate the problem of release notes, we will publish a list of new features in the upcoming LTS relative to the last LTS six months before it comes out. This means that about the time when 1.22 comes out, we'll have an announcement for 1.19 users letting them know what changes they can expect in 1.23. * Point releases will be made periodically. Frequency TBD. Every point release will include updated i18n files as well as any bug fixes. No new features will be back-ported to point releases. Thanks, Mark. -- http://hexmode.com/ There is no path to peace. Peace is the path. -- Mahatma Gandhi, "Non-Violence in Peace and War"

5 6

Proper category collation support finally implemented!
by Bartosz Dziewoński 02 Mar '13

02 Mar '13

Just yesterday I managed to get https://gerrit.wikimedia.org/r/#/c/49776/ merged. Based heavily on Tim's work on the IcuCollation, it allows one to *finally* get articles to be correctly sorted on category pages for 67 languages based in latin, greek and cyrillic alphabets. I also created https://bugzilla.wikimedia.org/show_bug.cgi?id=45443 to track the process of getting this deployed to Wikimedia wikis. The process is already underway for uk.wiki and pl.wiki; if anybody technical wishes to get it on their wiki first, please create a sub-bug and start a community discussion/vote - I can provide a testwiki in your language :) Eventually, I'd like this to be deployed on all wikis in those 67 languages. I'll start poking people about this (and will drop a mail to -ambassadors) once wmf11 is deployed and the change goes live on a few wikis. -- Matma Rex

6 12

Purpose of #wikimedia-dev
by Petr Bena 28 Feb '13

28 Feb '13

Hi, as Gry in #wikipedia recently mentioned, there is no IRC channel for general wikimedia developer purposes - project wide and language wide. There are subchannels for certain projects, but no general channel for wikimedia devs of all kinds from all projects. I suppose we could use #wikimedia-dev as a general channel for all developers no matter of project or programming language. What do you think? Bellow is a message written by Gry who doesn't want to be part of this mailing list ------- from gry@irc://irc.freenode.net/#wikipedia --------- Hi, Could we make an IRC channel dedicated to development of software for wikimedia projects (bots, js tools like twinkle, irc bots, etc)? Some people who work on some software for few wikimedia projects would likely benefit if they had a place to discuss its implementation, other than just ask #wikipedia (the largest channel of all). As the questions may get more tricky at times, a smaller, more development-minded channel could be a tad more effective at actually helping (regardless of what project they're from, be that wikipedia or wikibooks or something else). There currently is #wikimedia-dev which actually is a place for #mediawiki devs to meet, but they're not too happy with two channels either [1] and it could be possible to discuss a take over. Or otherwise a new channel named, say, #wikimedia-devel. [1] http://bots.wmflabs.org/~wm-bot/logs/%23mediawiki/20130123.txt from 12:59

11 25

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 February 2013