Wikitech-l October 2013

wikitech-l@lists.wikimedia.org

148 participants
149 discussions

Welcome to Ken Snider, Wikimedia Operations
by Erik Moeller 28 Jan '14

28 Jan '14

Hello all, I’m delighted to announce that Ken Snider is joining the Wikimedia operations team. He will start as an international contractor working remotely from Toronto, Canada on June 10, and will be visiting SF in the week of June 17. We’re currently in the process of seeking work authorization in the United States in the Director of TechOps position. CT has graciously agreed to support the ops leadership transition full-time through June, and part-time through July. We’ll be starting the handover while Ken is working remotely. A bit more about Ken: Ken was apparently genetically predisposed to become a sysadmin since he joined one of Canada’s first large ISPs, Primus, straight out of school in 1997 and helped build their infrastructure til 2001. He then joined a startup called OpenCOLA in 2001 which was co-founded by Cory Doctorow and developed early P2P precursors to tools like BitTorrent and Steam. It’s best known today for the development of an open source (GPL’d) cola recipe which is still in use (more than 150,000 cans sold if Wikipedia is to be believed). Ken got involved in one of Cory’s pet projects, BoingBoing.net which some of you may have heard of ;-), and has been their sysadmin since 2003. After a stint from 2001-2005 at DataWire, Ken became Director of Tech Ops at Federated Media, a role he held from 2005-2012. Federated Media is an ad network that was founded to support high traffic blogs and sites that want to stay independent of large publishers, with a network that supports more than 1B requests/day. One of the unusual challenges at FM was that the company grew through acquisitions of various blogging and publishing networks. This led to the challenge of integrating very heterogeneous operations and engineering infrastructure, including multiple geographically distributed ops teams and data-center locations. As DTO, Ken led these efforts, such as OS standardization, development of a unified deployment infrastructure, etc. Ken also ensured that the operations group partnered effectively with the various engineering teams developing site features and enhancements. I want to again take this opportunity to thank CT Woo for his tireless operations leadership since December 2010. I’d also like to thank everyone who’s participated in the Director of TechOps search process. Please join me in welcoming Ken to the Wikimedia Foundation and the community. :-) All best, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

4 4

!ask
by Ori Livneh 24 Jan '14

24 Jan '14

Can we deprecate usage of '!ask' on IRC? > ori-l: !ask > wm-bot: Hi, how can we help you? Just ask your question. It's annoying when people ask to ask, but the people who do so do it out of insecurity or lack of experience, and so they're the last people we should be siccing our bots on. I've used '!ask' a lot before but I'm going to stop. I hope others do the same.

9 10

Call for participation: Wikis devroom at FOSDEM
by Quim Gil 02 Dec '13

02 Dec '13

Spread the news! https://lists.fosdem.org/pipermail/wikis-devroom/2013-October/000000.html Wikis devroom - FOSDEM, Brussels, 1 & 2 February 2014 CALL FOR PARTICIPATION IN SHORT We accept proposals for wiki related submissions. The formats accepted are 25min sessions or 5min lighting sessions. All proposals must be submitted via https://penta.fosdem.org/submission/ Deadline: 30 November 2013 Questions? Feedback? Willing to help? https://lists.fosdem.org/listinfo/wikis-devroom BACKGROUND Wikis are essential tools for online collaboration, open knowledge and free software. They are everywhere: from the mainstream Wikipedia to a myriad of public, academic and corporate knowledge bases and personal sites. And most of them are open source software. Wikis became popular thanks to the edit button allowing users to create and modify text-based web pages easily. Over the years wikis have become more powerful, handling more content types, allowing better look & feel, championing localization and integrating (sometimes) with other tools. The development continues, with hundreds of professional and volunteer contributors specializing in this area. There are also challenges: the competition from (mainly proprietary and corporate) social media and online office tools, keeping up with UX expectations from users, editors and sysadmins, compatibility across different wiki engines and other publishing tools, collaboration between wiki projects... SCOPE Wikis devroom is a place to showcase and discuss * new features, especially exploring areas beyond plain text editing * compatibility and integration with other tools and services * lessons learned from deployments, surveys, research... * cross-project collaboration We want to focus on sessions for a technical audience including savvy editors. Basic introductions for end users and long tutorials are out of scope. FORMAT One day, one room. Most of the schedule will be filled with sessions of about 25 minutes that have gone through a call for participation. We will have a WikiWiki Hour of lightning presentations (5 minutes each). We will organize a panel session with representation of key wiki projects - the specific topic to be decided as we confirm the participants. ORGANIZATION Quim Gil (MediaWiki), Vincent Massol (XWiki) and Jean-Marc Libs (Tiki).

3 4

Bugzilla Weekly Report
by reporter 14 Nov '13

14 Nov '13

8 11

jQuery UI may not be loaded by default on your wiki
by Matthew Flaschen 14 Nov '13

14 Nov '13

We have merged a couple changes so that jQuery UI is not loaded by code that doesn't need it. See https://bugzilla.wikimedia.org/show_bug.cgi?id=55550 for details. That means gadgets and user scripts that use jQuery UI should explicitly load the appropriate module. https://www.mediawiki.org/wiki/Extension:Gadgets has info on adding gadget dependencies. User scripts can use mw.loader.using (https://www.mediawiki.org/wiki/RL/DM#mw.loader.using). A list of jquery.ui modules is at https://www.mediawiki.org/wiki/RL/DM#jQuery_UI . There is one remaining issue that may affect a few wikis. If your wiki uses jquery.ui buttons in wikitext, the styles will not be loaded unless something explicitly loads or depends on jquery.ui. If you notice styles missing from your wiki, you can add: // Load jquery.ui.button so button styles work in wikitext mw.loader.using( 'jquery.ui.button' ); to the site Common.js Don't do this unless it's actually needed, since this does have a performance impact (although it is not loading all of jquery.ui). If you do add it, please include the comment so people know why it's being loaded. This will roll out to the test wikis, plus MW.org, 2013-10-31, the remaining non-Wikipedia wikis the 4th, and the Wikipedias, the 7th. Matt Flaschen

1 1

migrating hooks doc to doxygen?
by Antoine Musso 13 Nov '13

13 Nov '13

Hello, Since we introduced hooks in MediaWiki, the documentation has been maintained in a flat file /docs/hooks.txt . Over the week-end I have converted the content of that file to let Doxygen recognize it. The patchset is: https://gerrit.wikimedia.org/r/#/c/66128/ I have used that patch to generate a temporary documentation. That lets everyone browse the result easily. The produced result is: A landing page: https://doc.wikimedia.org/mw-hooks/hooks_mainpage.html The doc overview: https://doc.wikimedia.org/mw-hooks/page_hooks_documentation.html A list of hooks with their documentation: https://doc.wikimedia.org/mw-hooks/page_hooks_list.html I think that makes it a bit more accessible to everyone and Doxygen autolink to referenced classes. Some issues I have: - the hooks are listed alphabetically when they could be regrouped by theme (like API, SpecialPages, HTML Forms ...). - The hooks are documented in a separate file (still docs/hooks.txt), when we might want to have the doc near the wfRunHooks() call. Thoughts ? -- Antoine "hashar" Musso

13 17

$wgRedactedFunctionArguments
by Ori Livneh 13 Nov '13

13 Nov '13

The 1.22 release adds a new configuration variable, $wgRedactedFunctionArguments, that allows administrators of MediaWiki installations to designate function arguments that should be redacted from stack traces. For example: $wgRedactedFunctionArguments[] = array('User::comparePasswords' => array( 0, 1 ) ) This value specifies that whenever the method User::comparePasswords appears in an exception stack trace, the value of the first and second arguments are to be redacted, meaning the string 'REDACTED' is inserted where the argument value would otherwise appear. The case for this feature was made in <https://bugzilla.wikimedia.org/show_bug.cgi?id=30714>. I think that it is a design blunder, and that we should remove it from MediaWiki. The task of making $wgRedactedFunctionArguments comprehensive is hopelessly gargantuan. It would require something like a full trace of the flow of data throughout all of MediaWiki and its extensions. The best case scenario is that the feature is not used. The worst case -- which seems to be materializing, judging by the default value assigned to it in DefaultSettings.php -- is that it is used with a short and chronically out-of-date list of obvious suspects, and that the resultant traces leak private data. This is actually worse than making no attempt at all to sanitize traces, because it is liable to mislead and inspire false feelings of confidence. I think that the proper way to handle low-level operational data like stack traces is to make it clear that it is liable to contain sensitive information, and to make no pretense at all of sanitizing it. If there is a credible need for outputting redacted traces, the output should exclude *all* values, not just the ones that someone remembered to configure. --- "Base access decisions on permission rather than exclusion. This principle...means that the default situation is lack of access, and the protection scheme identifies conditions under which access is permitted. The alternative, in which mechanisms attempt to identify conditions under which access should be refused, presents the wrong psychological base for secure system design. A conservative design must be based on arguments why objects should be accessible, rather than why they should not. In a large system some objects will be inadequately considered, so a default of lack of permission is safer. A design or implementation mistake in a mechanism that gives explicit permission tends to fail by refusing permission, a safe situation, since it will be quickly detected. On the other hand, a design or implementation mistake in a mechanism that explicitly excludes access tends to fail by allowing access, a failure which may go unnoticed in normal use. This principle applies both to the outward appearance of the protection mechanism and to its underlying implementation." ("The Protection of Information in Computer Systems", http://web.mit.edu/Saltzer/www/publications/protection/Basic.html) --- Ori Livneh ori(a)wikimedia.org

8 8

Architecture Summit: participants confirmed
by Quim Gil 08 Nov '13

08 Nov '13

Hi, https://www.mediawiki.org/wiki/Architecture_Summit_2014#Participants has been updated in order to reflect the current list of participants confirmed. We are in touch with a few contributors from areas currently underrepresented, and it is possible that some people are still added to the list. Volunteer contributors requiring sponsorship will be contacted via email. The Wikimedia Foundation will cover their flights and accommodation. Please email me if you don't hear from us this week. Wikimedia Foundation employees not based in San Francisco must contact their managers for travel arrangements. The first MediaWiki Architecture Summit 2014 is looking great at least in terms of participation. Next: content. Now it's time to focus in the discussions prior to the event, and the schedule. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

2 2

Optimizing the deployment train schedule
by Erik Moeller 08 Nov '13

08 Nov '13

Hi folks, after speaking to a few folks, I'd like to check in on the WMF deployment train schedule overall, and see if there are ways to optimize it. (Note: In the below I refer to "test wikis" vs. "production wikis", generously including mediawiki.org as a test wiki. I realize that our "test wikis", with the exception of Labs wikis, run on the production cluster.) == Current practice == * On Thursdays we increase the release counter, and deploy the latest release to test wikis and the previous one to Wikipedias. * On Mondays we deploy the latest release to non-Wikipedias. == Problems with this approach == * We only have bits of Thursday and all of Friday to resolve issues that are surfaced in the test wikis prior to the Monday rollout to the first production wikis. * Having two stages of release also increases the cognitive load on developers in understanding when their code hits production wikis, which arguably increases the risk of negative impact of a deploy going unnoticed. == Advantages of this approach == * Commons serves just about enough traffic to sometimes act as a useful canary for performance/scaling issues that will later appear in production. * Developers have some post-deployment time to fix issues highly specific to the non-Wikipedia wikis (e.g. extensions & gadgets only deployed there) rather than being distracted by firefighting on Wikipedia == Some options == Option A: Change nothing. I've not heard from enough folks to see if the problems above are widely perceived to _be_ problems. If the consensus is that current practice, for now, is the best possible approach, obviously we should stick with it. Option B: No Monday deploy. This would mean we'd have to improve our testing process to catch issues affecting the non-Wikipedia wikis before they hit production. I personally think getting rid of the Monday deploy could create some _desirable_ pain that would act as a forcing function to improve pre-release test practices, rather than using production wikis to test. At the same time, we'd have a full week to work out the kinks we find in testing before they hit any production wiki, and could have a more systematic process of backing out changes if needed prior to deployment. Option C: Shift Monday deploys to Tuesday. This would at least give us an additional work day to fix issues that have occurred in testing before they hit prod. I personally don't think this goes far enough, but might be a useful tweak to make if option B seems too problematic. Are there other ways to optimize / issues I'm missing or misrepresenting above? Thanks, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

13 20

Possible topics for the next RFC review
by Rob Lanphier 05 Nov '13

05 Nov '13

Hi folks, Here's the RFCs that have the most interest expressed on the Architecture Summit invite page[1]: https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database https://www.mediawiki.org/wiki/Requests_for_comment/Deprecating_inline_styl… https://www.mediawiki.org/wiki/Requests_for_comment/Password_requirements It's conceivable that Tim and/or Brion could hold an IRC meeting next week, if there's sufficient interest in doing so and they get a little help organizing it. There's perhaps a little pre-meeting setup, some notetaking, and post-meeting wiki gnoming to do. You can check out the meeting from September 24[2] to get an idea of what's needed. Also, there's now a meeting hub[3] for these meetings so that you can see what's coming up and dig up notes from previous meetings a little easier. The more we can get done online prior to the meeting, the more useful our in-person meeting will be in January. Unless we get everything done before the meeting and have nothing to do. I somehow don't think that'll be a problem. :-) Rob [1] https://www.mediawiki.org/wiki/Architecture_Summit_2014 [2] https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-09-24 [3] https://www.mediawiki.org/wiki/Architecture_meetings

5 5

Jump to page:

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