Wikitech-l April 2013

wikitech-l@lists.wikimedia.org

174 participants
209 discussions

Deployment Highlights - Week of April 29th
by Greg Grossmeier 26 Apr '13

26 Apr '13

Hello and welcome to the latest installment of the Deployment Highlights email. The full calendar for next week lives at: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_April_22nd For the week of April 22nd we have the following interesting deployments (which is much less interesting than last week, thankfully in some ways): == Monday == * MediaWiki 1.22wmf3 to 'phase 1' wikis (ie: test.wikipedia.org, * test2.wikipedia.org and mediawiki.org) ** https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_depl… == Tuesday == * Internationalization team: ** For bug 46716 we will run a script refresh-translatable-pages.php for all wikis using the Translate extension. It will ensure that all translation pages will be up to date. As a side effect, it will also remove any fuzzy/outdated translations still left in translation pages (many of those have already been removed due to updates triggered by translation edits). * Editor Engagement Team (E2) ** Notifications (formerly Echo) will be rolled out to English Wikipedia after the planned deployment for Thursday April 25th was delayed. == Wednesday == * MediaWiki 1.22wmf3 to 'phase 2' wikis ** All non-Wikipedia sites (Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites ** https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_depl… == Thursday == * Normal Editor Engagement and Editor Engagement Experiments deploy * windows. == Friday == * NO DEPLOYS! ;-) == All week == * Lightning Deploys! ** https://wikitech.wikimedia.org/wiki/Lightning_deployments == Hat tip == * Thanks to Matt Walker for creating a lua template for use in the * Deployments calendar! ** http://wikitech.wikimedia.org/wiki/Module:Deployment_schedule Best, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

retired services / Tampa cleanup
by Daniel Zahn 26 Apr '13

26 Apr '13

Hi, as part of our ongoing efforts to remove all unused, non-cluster remnants services from Tampa, all of the following services have been permanently retired. (This means removed from DNS, backup docroots and configs, then nuked. Almost all of them had been temp. disabled in the past so it's not like they were reachable for the public until yesterday) -- former websites on "singer". (Tampa misc host for off-cluster sites) -- communicate.wikimedia.org outreachcivi.wikimedia.org ocs.wikimania2009.wikimedia.org url.wikimedia.org wm08reg.wikimedia.org wm09schols.wikimedia.org wm10schols.wikimedia.org -- pre-labs things -- prototype.wikimedia.org en.prototype.wikimedia.org de.prototype.wikimedia.org tesla.usability.wikimedia.org tesla.wikimedia.org -- misc-- internproxy.wikimedia.org volunteer.wikimedia.org (this was already commented out in the past) survery.wikimedia.org argon.wikimedia.org wikitech-old.wikimedia.org (we got rid of the Linode instance) -- kept for backwards compatibiliy -- voip.wikimedia.org (but if your client uses that, please update to " voip.corp.wikimedia.org") -- kept for historic reasons -- long live .. coffee.wikimedia.org :) -- backed up docroots from singer on tridge -- blog.tar.gz bugzilla.tar.gz outreachcivi.tar.gz svn_blog.tar.gz techblog.tar.gz wm09schols_info.txt.gz wm10reg.tar.gz bugzilla.older.tar.gz bzapi.tar.gz survey.tar.gz svn_techblog.tar.gz wikimania2009.tar.gz wm09schols.tar.gz wm10schols.tar.gz .. and more -- about to be moved -- contacts.wikimedia.org racktables.wikimedia.org -- Daniel Zahn <dzahn(a)wikimedia.org> Operations Engineer

4 5

open add-more-debugging-info bugs
by Sumana Harihareswara 26 Apr '13

26 Apr '13

Would you like to improve our debugging, logging, or monitoring infrastructure to make it faster to troubleshoot problems? "Gimme more debug info" bugs: * Wikimedia Labs: Make instance creation failures more verbose * MediaWiki core: Report more information about php warnings * MWSearch extension: include the debug comment about where search results originated even for empty result sets Bigger implementation gaps: * Rework API error reporting * ResourceLoader: Implement feature for logging in debug mode * ResourceLoader: Support source maps for debugging production ResourceLoader JS Bug list: https://bugzilla.wikimedia.org/buglist.cgi?bug_id=43086,37763,45514,45843,4… (Thanks to Andre Klapper for assembling this.) -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

1 0

Have production server access? Please read this document
by Leslie Carr 25 Apr '13

25 Apr '13

The Ops team has been working on a document about best practices with regards to production machines. If you have access to a production machine, please read this document https://wikitech.wikimedia.org/wiki/Server_access_responsibilities -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/

2 1

Call for new list moderators
by Chad 25 Apr '13

25 Apr '13

Hi everyone, As you may have remembered reading. Huib--our longtime volunteer moderator for mediawiki-l and wikitech-l--resigned from his positions back in February[0]. I let this slip longer than I should've, but I'd like to now make the call for a new batch of list moderators for mediawiki-l and wikitech-l. I think it's very important to have more than one moderator per list, so I'm looking for several candidates to help with moderation with one (or both) lists. It's a pretty low maintenance job (the occasional spammer), as Huib and myself have always had a very light-handed moderation policy and have preferred to let discussions run their course. So, if this is something you're interested in helping out with, please respond to this off-list and tell me why. Don't need an essay, just a sentence or two about who you are and why you'd like to volunteer. I'll give it a couple of days for people to think about it and e-mail me, and I'll pick some people by late next week. Thanks, and have a good weekend :) -Chad [0] http://lists.wikimedia.org/pipermail/wikitech-l/2013-February/066320.html

1 1

GSoC query regarding jQuery.ime project
by Praveen Singh 25 Apr '13

25 Apr '13

Hi, I am Praveen Singh, a final Year Computer Science Graduate student at JIIT, India. I wish to apply for GSoC 2013 and I am thinking about jQuery.ime extensions for Firefox and Chrome as a project for the same. What I understood about the jQuery.ime project after going through its Github repository <https://github.com/wikimedia/jquery.ime> is : - It provides multilingual input support for the editable fields on a page. - Rules and keyboard mappings for different languages are defined in different js files for corresponding languages. Does the project simply aims at packaging the source files into an extension ? If so, doesn't that sounds a pretty small project for the complete GSoC timeline ? (Your thoughts ?) Or is it the fact that we need to develop two different extensions (for firefox and chrome), that makes it a good enough project for GSoC ? Enlighten me if I am not clear with the objectives of the project. Thanks, Praveen Singh

2 2

Zuul (gerrit/jenkins) upgraded
by Antoine Musso 25 Apr '13

25 Apr '13

Hello, This morning was very quiet so I have been bold and upgraded our Zuul installation. The new version comes with: - faster reporting (we have been hit by that a few weeks ago) - various performances improvement - configuration validation (I have setup the Jenkins job already) - support for Gerrit events introduced in 2.5/2.6 - statistics reporting (though that needs statds) - customization of success and failure messages Overall, there is no user facing change. Next steps would be customizing the messages a bit and complete the Debian package to make upgrades easier. Thanks to Faidon for all his help while packaging the python modules dependencies. cheers, -- Antoine "hashar" Musso

3 2

Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
by Yuvi Panda 25 Apr '13

25 Apr '13

For wider distribution! ---------- Forwarded message ---------- From: Jon Robson <jdlrobson(a)gmail.com> Date: Tue, Apr 23, 2013 at 5:13 AM Subject: [WikimediaMobile] Rethinking MobileFormatter / Skins To: mobile-l <mobile-l(a)lists.wikimedia.org> I've been playing around with skins a lot recently. The MobileFrontend extension has had to do various transformations to the content pre-rendering to ensure certain things do not get rendered on mobile (for example table of contents) as well as allow us to do collapsible sections. When rendering content skins are currently limited to rendering the 'bodytext' key. They cannot retrieve the underlying content. I would like to remove restrictions to skin designers - for instance currently a skin designer has no control over where the table of contents should do. They could not easily put it in a side bar for instance. I was experimenting with using the onOutputPageParserOutput hook [1] (running based on the current skin) and think it might be a better approach to run the transformations on smaller chunks of data. For instance the table of contents is known to be in the lead section so it seems like it would be more efficient to look for it there rather than throughout the entire document. The solution is not complete but provides an approach that I think would be more efficient on the long term. It seems like a good idea to experiment with this approach in MobileFrontend extension with the goal to upstream it to core. Would appreciate comments from people who know this area of code rather well - Max comes to mind :) Thoughts welcomed! [1] https://gist.github.com/jdlrobson/5439509 _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l -- Yuvi Panda T http://yuvi.in/blog

6 8

Usage of Wikidata: the brilliance of Wikipedians
by Denny Vrandečić 25 Apr '13

25 Apr '13

I am completely amazed by a particularly brilliant way that Wikipedia uses Wikidata. Instead of simply displaying the data from Wikidata and removing the local data, a template and workflow is proposed, which... * grabs the relevant data from Wikidata * compares it with the data given locally in the Wikipedia * displays the Wikipedia data * adds a maintenance category in case the data is different This allows both communities to check the maintenance category, provide a security net for vandal changes, still notice if some data has changed, etc. -- and to phase out the local data over time when they get comfortable and if they want to. It is a balance of maintenance effort and data quality. I am not saying that is the right solution in every use case, for every topic, for every language. But it is a perfect example how the community will surprise us by coming up with ingenious solutions if they get enough flexibility, powerful tools, and enough trust. Yay, Wikipedia! The workflow is described here: < http://en.wikipedia.org/wiki/Template_talk:Commons_category#Edit_request_on… > There is an RFC currently going on about whether and how to use Wikidata data in the English Wikipedia, coming out of the discussion that was here a few days ago. If you are an English Wikipedian, you might be interested: < http://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Wikidata_Phase_2 > -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

1 0

Re: [Wikitech-l] Ideating on GSoC project : Mobilize Wikidata
by Pragun Bhutani 24 Apr '13

24 Apr '13

Based on a discussion I had with YuviPanda and MaxSem on #wikimedia-mobile, I've got a few things to add: - It might be a good idea to let Wikidata detect when it's being accessed through a mobile device and then have it adjust the widths and such of the box-structures accordingly and then pass them to MobileFrontend. Maybe we can set up a Wikilabs instance with MobileFrontend like Quim Gil suggested and then we can see how much work there is involved with trying to make WIkidata mobile-friendly. If we can get it to work with MobileFrontend, that'll be excellent but if it turns out to be too complex or too dirty a solution, it would make more sense to make a completely new extension for it. Although the scope of the project is not very clear at the moment, I think that a feasible implementation plan could be worked out with respect to the GSoC timeline and if it's required, I can continue to work on the project after GSoC ends. On Tue, Apr 9, 2013 at 6:49 PM, Quim Gil <qgil(a)wikimedia.org> wrote: > On 04/09/2013 02:39 AM, Denny Vrandečić wrote: > >> I would hope >> > > It would also be extremely good to look >> > > > I would assume > > I don't think >> > > Can the Wikidata and Mobile teams please answer with the best of your > knowledge to the questions at > > Bug 43065 - WikibaseRepo to be mobile friendly (tracking) > https://bugzilla.wikimedia.**org/show_bug.cgi?id=43065<https://bugzilla.wikimedia.org/show_bug.cgi?id=43065> > > Beyond hope and believe, the fact is that I couldn't get any answer more > precise than "Interesting" when asking about this project to people in > those teams. And as for today I'm not confident to tell to a candidate like > Pragun whether this project is too complex or too simple, and where the > complexity/simplicity relies. > > In case of doubt I'd prefer to play safe and actually not encourage GSOC / > OPW to apply for a project like this, before we regret around August. > > Is it possible to have a Wikidata / WikidataRepo test instance somewhere > with MobileFrontend enabled, so we can all have a look and know more about > the gap this project should fill? > > -- > Quim Gil > Technical Contributor Coordinator @ Wikimedia Foundation > http://www.mediawiki.org/wiki/**User:Qgil<http://www.mediawiki.org/wiki/User:Qgil> > > > ______________________________**_________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l> > -- Pragun Bhutani http://pragunbhutani.in Skype : pragun.bhutani

5 8

← Newer
1
...
5
6
7
8
9
10
11
...
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 April 2013