Wikitech-l January 2015

wikitech-l@lists.wikimedia.org

133 participants
121 discussions

[x-posting] Raising attention for the API bug
by Amir Ladsgroup 01 Feb '15

01 Feb '15

Hello, This bug <https://phabricator.wikimedia.org/T87645> is more serious than it seems and it's blocked a huge part of our actions (e.g. creating pages outside of main namespace via API) Please someone take a look at this -- Amir

3 3

Fixing a problem in CollapsibleVector
by Thomas Mulhall 01 Feb '15

01 Feb '15

Hi could I have some help to fix a problem that a user reported on the extension talk page. The talk page is at http://www.mediawiki.org/wiki/Extension_talk:CollapsibleVector and the title is flickering. I am not sure how to fix the problem I was wandering if someone on here knew how to fix the problem.

1 1

Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
by Tilman Bayer 31 Jan '15

31 Jan '15

Minutes and slides from four recent quarterly reviews are now available: Team Practices Group: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… Engineering Commmunity Team: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… Release Engineering and QA (Quality Assurance) team: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… Mobile Partnerships (Wikipedia Zero) team: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote: > Hi folks, > > to increase accountability and create more opportunities for course > corrections and resourcing adjustments as necessary, Sue's asked me > and Howie Fung to set up a quarterly project evaluation process, > starting with our highest priority initiatives. These are, according > to Sue's narrowing focus recommendations which were approved by the > Board [1]: > > - Visual Editor > - Mobile (mobile contributions + Wikipedia Zero) > - Editor Engagement (also known as the E2 and E3 teams) > - Funds Dissemination Committe and expanded grant-making capacity > > I'm proposing the following initial schedule: > > January: > - Editor Engagement Experiments > > February: > - Visual Editor > - Mobile (Contribs + Zero) > > March: > - Editor Engagement Features (Echo, Flow projects) > - Funds Dissemination Committee > > We’ll try doing this on the same day or adjacent to the monthly > metrics meetings [2], since the team(s) will give a presentation on > their recent progress, which will help set some context that would > otherwise need to be covered in the quarterly review itself. This will > also create open opportunities for feedback and questions. > > My goal is to do this in a manner where even though the quarterly > review meetings themselves are internal, the outcomes are captured as > meeting minutes and shared publicly, which is why I'm starting this > discussion on a public list as well. I've created a wiki page here > which we can use to discuss the concept further: > > https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r… > > The internal review will, at minimum, include: > > Sue Gardner > myself > Howie Fung > Team members and relevant director(s) > Designated minute-taker > > So for example, for Visual Editor, the review team would be the Visual > Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. > > I imagine the structure of the review roughly as follows, with a > duration of about 2 1/2 hours divided into 25-30 minute blocks: > > - Brief team intro and recap of team's activities through the quarter, > compared with goals > - Drill into goals and targets: Did we achieve what we said we would? > - Review of challenges, blockers and successes > - Discussion of proposed changes (e.g. resourcing, targets) and other > action items > - Buffer time, debriefing > > Once again, the primary purpose of these reviews is to create improved > structures for internal accountability, escalation points in cases > where serious changes are necessary, and transparency to the world. > > In addition to these priority initiatives, my recommendation would be > to conduct quarterly reviews for any activity that requires more than > a set amount of resources (people/dollars). These additional reviews > may however be conducted in a more lightweight manner and internally > to the departments. We’re slowly getting into that habit in > engineering. > > As we pilot this process, the format of the high priority reviews can > help inform and support reviews across the organization. > > Feedback and questions are appreciated. > > All best, > Erik > > [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus > [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate > > _______________________________________________ > Wikimedia-l mailing list > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB

1 0

Converting debug logging to PSR-3
by Bryan Davis 30 Jan '15

30 Jan '15

PSR-3 logging has been fully supported in MediaWiki since1.25wmf5. We've been making various tuning improvements since then including a recent deprecation of the initial MWLogger wrapper class in favor of direct usage of Psr\Log\LoggerInterface by wfDebugLog() and other internal wrapper methods [2]. The next big step in introducing structured logging to MediaWiki is to begin to replace calls to wfDebugLog() (and dear god wfDebug()) with direct usage of Psr\Log\LoggerInterface instances. Kunal and I have a couple starter patches that show this in gerrit [3]. In both conversions we have chosen to implement Psr\Log\LoggerAwareInterface in the effected classes to allow setter based injection of a LoggerInterface. The log channel names were also chosen to match the previous wfDebugLog logGroup values. When you use a PSR-3 logger you need to choose a severity for each log message. PSR-3 has quite a few possible levels, but I'd like to propose that we really only need 4 to start with in MediaWiki: * debug: Useful for ummm.... debugging. :) These are messages that are useful for local development and are generally too "spammy" to output on a production wiki. This would typically include anything currently being logged via wfDebug. * info: Valuable state change information. This level is a great place to record information that would be useful in a production environment when tracing the path of a request that eventually had an error. * warning: A soft error condition such as a recoverable error or another condition that typically should not be seen but isn't halting for the operation in process * error: A hard error such as a caught exception with no recovery path. The notice, critical, alert and emergency log levels seem unnecessary to me, but I'm willing to hear arguments about where they are super duper useful for some log event state that I haven't thought of yet. When thinking about Wikimedia cluster logging, events emitted at warning and error levels should be things that you want deployers and operations staff to see in the Logstash "fatalmonitor" view and recorded to other durable logging stores. Events at info level may or may not be captured similar to how we currently enable some but not all wfDebugLog channels. Events at debug level will probably only be captured in beta labs and similar low volume debugging environments. The wfDebug* methods are not being deprecated officially yet but it would be great if people started treating them like they were deprecated when writing new classes. It would be even more awesome if more folks started making small cleanup patches to convert existing classes to the new style of logging. Tagging gerrit reviews for these patches with "PSR-3" as either a submitter or a reviewer would also be appreciated. [0]: https://gerrit.wikimedia.org/r/#/c/119940/ [1]: https://gerrit.wikimedia.org/r/#/c/185210/ [2]: https://gerrit.wikimedia.org/r/#/c/184830/ [3]: https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+branch:master+top… Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

5 5

Re: [Wikitech-l] From Node.js to Go
by Ori Livneh 30 Jan '15

30 Jan '15

(Sorry, this was meant for wikitech-l.) On Thu, Jan 29, 2015 at 7:20 PM, Ori Livneh <ori(a)wikimedia.org> wrote: > We should do the same, IMO. > http://bowery.io/posts/Nodejs-to-Golang-Bowery/ >

9 8

Re: [Wikitech-l] [WikimediaMobile] Florian for +2 on MobileFrontend?
by Tomasz Finc 30 Jan '15

30 Jan '15

CC'ing wikitech-l@ to broaden the reach of this --tomasz On Fri, Jan 30, 2015 at 10:32 AM, Jon Robson <jrobson(a)wikimedia.org> wrote: > I've proposed that Florian gets +2 on the MobileFrontend repository. > Florian has been an extremely active MobileFrontend developer (he is > our 5th most active contributor). > > It would be great to have him helping out with merging patches. He > also is based in Europe so it would strengthen our ability to get > regressions fixed on different timezones quicker! > > You can support this by voting using the {{support}} template on: > https://www.mediawiki.org/wiki/Gerrit/Project_ownership#.2B2_for_Florian_Sc… > > Please show your {{support}} on the wiki page to make this happen! > > (In the words of Spiderman with great power comes great reponsibility) > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l

1 0

MediaWiki Language Extension Bundle 2015.01 release
by Kartik Mistry 30 Jan '15

30 Jan '15

Hello all, I would like to announce the release of MediaWiki Language Extension Bundle 2015.01. This bundle is compatible with MediaWiki 1.23.8 and MediaWiki 1.24.1 releases. * Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2015.01.tar… * sha256sum: 7a53ed826ae14ffe279fc4231cc47d367f668723a5843ad62c13a8f17d339744 Quick links: * Installation instructions are at: https://www.mediawiki.org/wiki/MLEB * Announcements of new releases will be posted to a mailing list: https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n * Report bugs to: https://phabricator.wikimedia.org/ * Talk with us at: #mediawiki-i18n @ Freenode Release notes for each extension are below. -- Kartik Mistry == Babel, CLDR and CleanChanges == * Localisation updates only. == LocalisationUpdate == * T69154: Added support for updating skins. == Translate == * T44162: Patrol footer will not appear on translation pages now. * T76731: Added Content Translation Machine Translation backend support. * T86000: Message group configurations are now optionally validated. * Make 'fuzzy' as a default action for changes in source language in Special:ManageMessageGroups. == UniversalLanguageSelector == * This version has compatibility issues with Internet Explorer 8. Support will be restored in the next MLEB release. === Input Methods === * Corrected names of Punjabi input methods. -- Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_ {kartikm, 0x1f1f}.wordpress.com

1 0

Blog post on Librarization project published
by Bryan Davis 30 Jan '15

30 Jan '15

For the last four months, my main focus has been the Librarization project [0]. Today a wrap up blog post was posted to blog.wikimedia.org [1] that I'd invite all of you to read to get an overview of what our high level goals and motivations were and what we accomplished. The TL;DR is that we now have some guidelines for how to separate code from MediaWiki and publish it as a semi-autonomous open source project. The blog post ends with a thinly veiled call to action for MediaWiki developers to continue the work of extracting code from the current MediaWiki core application and publishing them as independent libraries. We've published some information on how to deal with git hosting, code review, and various other general issues on mediawiki.org [2]. There is also a list of some areas of the existing code base that we thought would be interesting targets for extraction [3]. The CDB library [4] can serve as one concrete example of using the guidelines. I'd like to invite anyone interested in starting work on decoupling a particular area of the code to start a thread on wikitech-l and file a task in Librarization phabricator project [5] to attract collaborators and help reduce possible duplication of effort. It would also be great to have edits on the list page and/or phabricator tasks to act as a wish list of things that know of in MediaWiki that you would either like to be able to use in a non-MediaWiki PHP project or feel would be a good candidate for isolation so that alternate implementations could be introduced. [0]: https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki [1]: https://blog.wikimedia.org/2015/01/29/modernizing-mediawiki-with-libraries/ [2]: https://www.mediawiki.org/wiki/Manual:Developing_libraries [3]: https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki/Library… [4]: https://www.mediawiki.org/wiki/CDB [5]: https://phabricator.wikimedia.org/tag/librarization/ Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

3 2

wfShellExec() quirk - advice needed on further debug
by Keith Welter 29 Jan '15

29 Jan '15

The GraphViz extension uses wfShellExec() to invoke the "dot" command. Sometime in the last month or so, on my Ubuntu 14.04 installation, the command started failing with: Warning: Could not load "/usr/lib/graphviz/libgvplugin_gd.so.6" - file not found The file does exist and the dot command runs fine from a shell session. I found that by eliminating the ulimit -v option from ulimit4.sh, which wfShellExec() invokes, the problem goes away. The -v limit is 102400 on my installation (so 100Mb). I find it hard to believe that dot actually needs that much virtual memory. Suggestions on how to proceed with debug would be much appreciated. Thanks, Keith Welter

2 2

Thoughts: stateless services with open servers?
by Brion Vibber 29 Jan '15

29 Jan '15

We had a great discussion at the MediaWiki dev summit just now on service-oriented architecture and future plans in that direction... as always the community seems a bit split on the subject. Breaking things out to separate services can indeed make setup and maintenance more complex... pro-services/pro-VM/pro-hosting folks like me tend to say "hey that can be automated!" (and MediaWiki-Vagrant shows a lot of awesomeness to start, though it's very developer-focused). One thing that comes to mind though is something Gabriel mentioned about wanting stateless services for things like image manipulation and citation parsing and whatnot -- in principle many services like this could be opened up to public use. For instance, a random MediaWiki instance could use a Wikimedia-hosted image scaler or graph rasterizer. Usage limits and API keys could be introduced if we're worried about overloading. Whether this can apply also to things like Parsoid might be tricky -- that's the biggest Scary Thing since core editing with VE/Flow is going to depend on it. Anyway, just thoughts. :) -- brion

14 26

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 January 2015