Wikitech-l December 2014

wikitech-l@lists.wikimedia.org

88 participants
99 discussions

Andrew Garret joins the Wikimedia Foundation
by Tomasz Finc 12 Dec '14

12 Dec '14

I am pleased to announce Andrew Garret joining the Wikimedia Foundation as a full time Software Engineer Andrew has been contracting with the Wikimedia Foundation for over six years now and its only fitting to announce that now that he's done with his studies he'll be going full time at the Wikimedia Foundation. In the past six years, he's worked on a huge variety of projects, ranging from user preferences and spam filtering to notifications and two attempts to fix talk pages. He's passionate about making people’s workflows and processes make sense, so in the coming months, he's looking forward to having the time and energy to focus on software that humanizes our projects, eliminates busy work, and makes life easier for new and old contributors. Right now Andrew is in the process of moving from Sydney to Maastricht to be with his girlfriend He'll be working from Maastricht; and from early next year, Prague. So if you find yourself in one of those cities, you should let him know! When not working, doing assignments, or packing bags, Andrew is busy travelling or homebrewing. He's currently supporting the Flow team and we're exploring where he'll help next. Please join me in celebrating Andrew going full time --tomasz

6 5

What to do with TimedMediaHandler
by Derk-Jan Hartman 11 Dec '14

11 Dec '14

So for a while now, I have been toying a bit with TimedMediaHandler/MwEmbed/TimedText, with the long term goal of wanting it to be compatible with VE, live preview, flow etc. There is a significant challenge here, that we are sort of conveniently ignoring because stuff 'mostly works' currently and the MM team having their plate full with plenty of other stuff: 1: There are many patches in our modules that have not been merged upstream 2: There are many patches upstream that were not merged in our tree 3: Upstream re-uses RL and much infrastructure of MW, but is also significantly behind. They still use php i18n, and their RL classes themselves are also out of date (1.19 style ?). This makes it difficult to get 'our' changes merged upstream, because we need to bring any RL changes etc with it as well. 4: No linting and code style checks are in place, making it difficult to assess and maintain quality. 5: Old jQuery version used upstream 6: Lot's of what we consider deprecated methodologies are still used upstream. 7: Upstream has a new skin ?? 8: It uses loader scripts on every page, which really aren't necessary anymore now that we can add modules to ParserOutput, but since I don't fully understand upstream, i'm not sure what is needed to not break upstream in this regard. 9: The JS modules arbitrarily add stuff to the mw. variables, no namespacing there. 10: The RL modules are badly defined, overlap each other and some script files contain what should be in separate modules 11: We have 5 'mwembed' modules, but upstream has about 20, so they have quite a bit more code to maintain and migrate. 12: Brion is working on his ogvjs player which at some point needs to integrate with this as well (Brion already has some patches for this [1]). 13: Kaltura itself seems very busy and doesn't seem to have too much time to help us out. Since some of the code is however highly specific to their use cases, it becomes difficult to validate changes. Oh and the file trees are disjunct between us and upstream, making git merging a lot more troublesome than it should be (anyone got tips ?). This is maintenance hell, we need to come up with a plan here or we are going the way of getting so far out of sync that the cheapest solution will be to start from scratch... So my questions: 1: Is there anything in upstream that we actually want ? I've been hearing about the 'update' that was still coming from there for over a year now, but due to how far both trees are now out of sync, i'm not really holding my breath for that anymore. The last 'proper sync' seems to have been 'Kaltura 1.7' in july 2012.[2] They are now at v2.21.9 2: Who can think of a strategy to fix this ? 3: Or should we just split off our modules and let upstream sort this out ? 4: Should we consider starting something from scratch ? DJ I have done a bit of cleanup [3] with jshint and jscs on the modules that we use. There are some remaining problems [4], some of which are true bugs in the code. I don't intend to propose these changes for merging any time soon, since it will probably make consolidation of the two variants even more complicated, but I'll try to keep it up to date and maybe try to fix some of these bugs upstream or in MW. [1] https://gerrit.wikimedia.org/r/#/c/165477/ https://gerrit.wikimedia.org/r/#/c/165478/ https://gerrit.wikimedia.org/r/#/c/165479/ [2] https://gerrit.wikimedia.org/r/#/c/16468/ [3] https://github.com/hartman/mwEmbed/compare/jscleanup [4] https://phabricator.wikimedia.org/P147

3 2

Re: [Wikitech-l] [Commons-l] Elog.io now up w/ Commons data
by Jonas Öberg 11 Dec '14

11 Dec '14

Hi Cornelius! For images which it match against the catalog, it should give accurate information. If it doesn't, use the "report" link to let us know! You're right though that for images it doesn't find in its catalog, we don't provide any information. That's the equivalent of saying "this picture may or may not be openly licensed, but right now we have no information to tell either way" Sincerely, Jonas On 11 Dec 2014 15:57, "Cornelius Kibelka" <cornelius.kibelka(a)wikimedia.de> wrote: > Wow, what a nice and interesting browser extension. Congrats! > > Just a question: as far as I can see the tool doens't give the complete > and correction licensing information, as the source is missing. Or I'm > missleading? > > Best > Cornelius > > 2014-12-10 19:30 GMT+01:00 Jonas Öberg <jonas(a)commonsmachinery.se>: > >> Dear all, >> >> thanks for all your help with answering questions and giving feedback >> over the last couple of months. I'm happy to say that we're finally at >> a stage where we've hashed 22,452,638 images from Wikimedia Commons >> and launched Elog.io in public beta: http://elog.io/ >> >> Elog.io is an open API as well as browser plugins, that can query and >> get information about images using a perceptual hash that's easy and >> quick to calculate in a browser. >> >> What the browser extensions allow you to do is match an image you find >> "in the wild" against Wikimedia Commons. If it can be matched against >> an image from Commons, it'll show you the title, author, and license, >> and give you links back to Wikimedia, the license, and a quick and >> handy "Copy as HTML" to copy the image and attribution as a HTML >> snippet for pasting into Word, LibreOffice, Wordpress, etc. >> >> Our API provides lookup functions to find information using a URL (the >> Commons' page name URL) or using the perceptual hash. You get >> information back as JSON in W3C Media Annotations format. of course, >> the information you get back is no better than the one provided by the >> Commons API, so if you already have a page name URL, you may as well >> query it directly, and rely on our API only for searching by >> perceptual hashes. >> >> The algorithm we use for calculating perceptual hashes, which you'll >> need to query our API, is at http://blockhash.io/ >> >> >> Sincerely, >> Jonas >> >> _______________________________________________ >> Commons-l mailing list >> Commons-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/commons-l >> > > > > -- > Cornelius Kibelka > > International Affairs > Werkstudent | student trainee > > Wikimedia Deutschland e.V. > Tempelhofer Ufer 23-24 > 10963 Berlin > > Tel.: +49 30 219158260 > http://wikimedia.de > > <http://wikimedia.de/>Stellen Sie sich eine Welt vor, in der jeder Mensch > freien Zugang zu der > Gesamtheit des Wissens der Menschheit hat. Helfen Sie uns dabei! > http://spenden.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. > > _______________________________________________ > Commons-l mailing list > Commons-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l > >

1 0

Wikimedia Phabricator down: Dec 18th 00:00-08:00 UTC
by Andre Klapper 11 Dec '14

11 Dec '14

Due to migrating most of RT to Phabricator, phabricator.wikimedia.org will be down and NOT AVAILABLE for eight hours starting on Thursday 18 December 00:00 UTC (that is Wed 17 Dec 16:00PST for people in San Francisco). In those eight hours, urgent issues which cannot wait should be brought up either on IRC or https://www.mediawiki.org/wiki/Project:Support_desk Thank you for your understanding and sorry for the inconvenience. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 0

All non-api traffic is now served by HHVM
by Giuseppe Lavagetto 10 Dec '14

10 Dec '14

Hi all, it's been quite a journey since we started working on HHVM, and last week (November 25th) HHVM was finally introduced to all users who didn't opt-in to the beta feature. Starting on monday, we started reinstalling all the 150 remaining servers that were running Zend's mod_php, upgrading them from Ubuntu precise to Ubuntu trusty in the process. It seemed like an enormous task that would require me weeks to complete, even with the improved automation we built lately. Thanks to the incredible work by Yuvi and Alex, who helped me basically around the clock, today around 16:00 UTC we removed the last of the mod_php servers from our application server pool: all the non-API traffic is now being served by HHVM. This new PHP runtime has already halved our backend latency and page save times, and it has also reduced significantly the load on our cluster (as I write this email, the average cpu load on the application servers is around 16%, while it was easily above 50% in the pre-HHVM era). The API traffic is still being partially served by mod_php, but that will not be for long! Cheers, Giuseppe -- Giuseppe Lavagetto Wikimedia Foundation - TechOps Team

11 13

You'll likely get a bunch of Diffusion e-mails
by Chad 10 Dec '14

10 Dec '14

The links may not go anywhere useful. Ignore them. I'm sorry. These e-mails shouldn't have gone out (and didn't in testing). The links should slowly start to work as things finish importing. Yay one time migration costs. Again, sorry for the possible deluge some of you may get. -Chad

3 3

[Reminder] Language Engineering IRC Office Hour on December 10, 2014 (Wednesday) at 1700 UTC
by Runa Bhattacharjee 10 Dec '14

10 Dec '14

Hello, A quick reminder about Language Engineering team's monthly IRC office hour later today at 1700 UTC on #wikimedia-office. Please see below for the original announcement, local time, and agenda. We will post logs on metawiki[1] after the event. Thanks Runa [1] https://meta.wikimedia.org/wiki/IRC_office_hours#Office_hour_logs Monthly IRC Office Hour: ======================= # Date: December 10, 2014 (Wednesday) # Time: 1700 UTC (Check local time: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20141210T1700) # IRC channel: #wikimedia-office # Agenda: 1. Updates from the Content Translation project 2. Q & A/Discussions ---------- Forwarded message ---------- From: Runa Bhattacharjee <rbhattacharjee(a)wikimedia.org> Date: Fri, Dec 5, 2014 at 11:26 AM Subject: [x-post] Language Engineering IRC Office Hour on December 10, 2014 (Wednesday) at 1700 UTC To: MediaWiki internationalisation <mediawiki-i18n(a)lists.wikimedia.org>, Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>, Wikimedia developers <wikitech-l(a)lists.wikimedia.org> [x-posted announcement] Hello, Please save the date for the monthly IRC office hour of the Wikimedia Language Engineering team on Wednesday, December 10, 2014 at 1700 UTC on #wikimedia-office. Project updates will include information about the new version of Content Translation[1] and plans for the next release. Please see below for event details and local time. Thanks Runa [1] https://www.mediawiki.org/wiki/Content_translation/Announcement-November2014 Monthly IRC Office Hour: ======================= # Date: December 10, 2014 (Wednesday) # Time: 1700 UTC (Check local time: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20141210T1700) # IRC channel: #wikimedia-office # Agenda: 1. Updates from the Content Translation project 2. Q & A/Discussions -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation

1 0

Which old RFCs to discuss on next week's RFC chat
by Daniel Kinzler 10 Dec '14

10 Dec '14

Hi all! The Architecture Committee, and especially Tim, has been going through the RFC backlog over the last moths. Many where discussed at the weekly RFC chat on Wednesdays, and most of these were resolved. But there are some rather old RFCs left, for which it's a bit unclear whether anyone is still interested in discussing them. So, if you like, go through the list below and tell us whether you would like to discuss an RFC, or think it should be abandoned, or amended, or rewritten, or whatever. * https://www.mediawiki.org/wiki/Requests_for_comment/Refactor_on_File-FileRe… This is a proposal to refactor media handling code. In particular, it proposes to split backend tasks performed by MediaHandler from UI related tasks. * https://www.mediawiki.org/wiki/Requests_for_comment/Drop_actions_in_favour_… This is a proposal to move away from action= in favor of Special pages. Perhaps obsolete, since action handling was rewritten since? * https://www.mediawiki.org/wiki/Requests_for_comment/Itemise_protection This argues that we should support multiple protections to apply to a page at once, e.g. indefinite semi-protection and at the same time a short-term full protection. I'd personally like to discuss this as part of a larger refactoring that would implement protection based on our permission system. Basically, applying protection would mean overriding which group has which permissions on a given page. * https://www.mediawiki.org/wiki/Requests_for_comment/Regex-based_blacklist A proposal to overhaul SpamBlacklist (from 2008). I'd personally be more interested in integrating this with (a rewrite of) AbuseFilter. We could have multiple lists, accessible from AbuseFilter rules. There are also some RFCs that relate to organizational issues rather than MediaWiki features and architecture as such: * https://www.mediawiki.org/wiki/Requests_for_comment/Release_notes_automation Automatically compose RELEASE-NOTES based on special lines in the git commit message. I like the idea! * https://www.mediawiki.org/wiki/Requests_for_comment/Distribution_and_deploy… This looks like a grand design, with very little information about what exactly it is supposed to do, and how. It's from 2010 and marked "incomplete". Anyone interested? * https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_Foundation This is about creating a governance group for MediaWiki, separate from Wikimedia. The release management for MediaWiki has since been moved to Mark Hershberger and Markus Glaser, but I don't know much about their arrangement with WMF. Is there still demand for a MediaWiki Foundation? Some good ideas here, and some old cruft. I think the most important factor in deciding what to discuss is to see for which RFCs there are people interested in working on them. So, please give us some feedback, ideally until Monday, so we can plan the RFC chat for Wednesday . Cheers, Daniel

4 7

RFC meeting this week
by Tim Starling 10 Dec '14

10 Dec '14

In this week's RFC meeting I think we should discuss the following RFC: * Drop actions in favour of page views and special pages <https://www.mediawiki.org/wiki/Requests_for_comment/Drop_actions_in_favour_…> Because it was mentioned in Daniel's wikitech-l thread. The meeting will be on the IRC channel #wikimedia-office on irc.freenode.org at the following time: * UTC: Wednesday 21:00 * US PST: Wednesday 13:00 * Europe CET: Wednesday 22:00 * Australia AEDT: Thursday 08:00 -- Tim Starling

1 0

Visibility of "action" in API for deleted log entries
by Chris Steipp 09 Dec '14

09 Dec '14

Hi list, I wanted to get some feedback about https://phabricator.wikimedia.org/T74222. In the last security release, I changed the return of the api to remove the "action" for log entries that had been revdeleted with "Hide action and target". However, ever since 2009 / r46917, we've assumed that "Hide action and target" didn't mean the actual action field in the db, but rather the target and the text of the message about the action, which might include other parameters. So the message about what's being hidden and the intended protection of that option could have slightly different interpretations. I'd like to hear if anyone has intended for the actual log action to be deleted / suppressed. If not, I'm happy to revert the recent patch, and we'll just update the wording in the deletion UI to be more clear about what is being removed.

6 7

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

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 December 2014