Wikitech-l March 2014

wikitech-l@lists.wikimedia.org

188 participants
234 discussions

Making it possible to specify MediaWiki compatibility in extensions
by Jeroen De Dauw 02 Mar '14

02 Mar '14

Hey, As you are probably aware of, it has been possible for some time now to install Composer compatible MediaWiki extensions via Composer. Markus Glaser recently wrote an RFC titled "Extension management with Composer" [0]. This RFC mentioned that it is not possible for extensions to specify which version of MediaWiki they are compatible with. After discussing the problem with some people from the Composer community, I created a commit that addresses this pain point [1]. It's been sitting on gerrit getting stale, so some input there is appreciated. [0] https://www.mediawiki.org/wiki/Requests_for_comment/Extension_management_wi… [1] https://gerrit.wikimedia.org/r/#/c/105092/ For your convenience, a copy of the commit message: ~~ Make it possible for extensions to specify which version of MediaWiki they support via Composer. This change allows extensions to specify they depend on a specific version or version range of MediaWiki. This is done by adding the package mediawiki/mediawiki in their composer.json require section. As MediaWiki itself is not a Composer package and is quite far away from becoming one, a workaround was needed, which is provided by this commit. It works as follows. When "composer install" or "composer update" is run, a Composer hook is invoked. This hook programmatically indicates the root package provides MediaWiki, as it indeed does when extensions are installed into MediaWiki. The package link of type "provides" includes the MediaWiki version, which is read from DefaultSettings.php. This functionality has been tested and confirmed to work. One needs a recent Composer version for it to have an effect. The upcoming Composer alpha8 release will suffice. See https://github.com/composer/composer/issues/2520 Tests are included. Composer independent tests will run always, while the Composer specific ones are skipped when Composer is not installed. People that already have a composer.json file in their MediaWiki root directory will need to make the same additions there as this commit makes to composer-json.example. If this is not done, the new behaviour will not work for them (though no existing behaviour will break). The change to the json file has been made in such a way to minimize the likelihood that any future modifications there will be needed. Thanks go to @beausimensen (Sculpin) and @seldaek (Composer) for their support. ~~ I also wrote up a little blog post on the topic: http://www.bn2vs.com/blog/2014/02/15/mediawiki-extensions-to-define-their-m… Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --

3 2

Labs migration starts on Tuesday
by Andrew Bogott 01 Mar '14

01 Mar '14

Starting on Tuesday, March 4th, the new Labs install in the eqiad data center will be open for business. Two dramatic things will happen on that day: Wikitech will gain the ability to create instances in eqiad, and wikitech will lose the ability to create new instances in pmtpa. About a month from Tuesday, the pmtpa labs install will be shut down. If you want your project to still be up and running in April, you must take action! We are committed to not destroying any instances or data during the shutdown, but projects that remain untouched by human hands during the next few weeks will be mothballed by staff: the data will be preserved but most likely compressed and archived, and instances will be left in a shutdown state. (Note: Toollabs users can sit tight for a bit; Coren will provide specific migration instructions for you shortly.) I've written a migration guide, here: https://wikitech.wikimedia.org/wiki/Labs_Eqiad_Migration_Howto It's a work in progress, so check back frequently. Please don't hesitate to ask questions on IRC, make suggestions as to guide improvements, or otherwise question this process. Quite a few of the suggested steps in that guide require action on the part of a Labs op -- for that purpose we've created a bugzilla tracking bug, 62042. To add a migration bug that links to the tracker, use this link: https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia%20Labs&compo… At the very least, please visit this page and edit it with your project migration plans: https://wikitech.wikimedia.org/wiki/Labs_Eqiad_Migration_Progress Projects that have no activity on that page will be early candidates for mothballing. If you want me to delete your project, please note that as well -- that will allow us to free up resources for future projects. I am cautiously optimistic about this migration. Most of our testing has gone fairly well, so a lot of you should find the process smooth and easy. That said, we're all going to be early adopters of this tech, so I appreciate your patience and understanding when inevitable bugs shake out. I look forward to hearing about them on IRC! -Andrew

2 2

Two factor auth reset needed on wikitech
by Matthew Walker 01 Mar '14

01 Mar '14

Wikitech admin peoples! I was doing bad things to my phone last night (reflashing it) and I lost the 2 factor auth metadata for my authentication app. Because of this I can no longer log in to wikitech. I wasn't able to find any documentation on wikitech about how to reset it -- so I need your help to do that I think? I still know my password; so I'm not looking to reset that -- maybe just temporarily disable two factor auth on my account (Mwalker) and I'll re-enroll myself? ~Matt Walker Wikimedia Foundation Fundraising Technology Team

4 7

Roadmap and Deployment highlight - week of March 3rd
by Greg Grossmeier 01 Mar '14

01 Mar '14

Hello and welcome to the latest edition of the WMF Roadmap and Deployments update. See the full roadmap for next week and beyond here: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_March_3rd Some important call outs: == Monday == The migration of WMF Labs from pmtpa to eqiad begins * new instance creation disabled in pmtpa, only available in eqiad * See the emails from Andrew and Marc for more details: ** http://lists.wikimedia.org/pipermail/labs-l/2014-February/002152.html ** http://lists.wikimedia.org/pipermail/labs-l/2014-February/002153.html We will be disabling ArticleFeedBack on all wikis. * https://bugzilla.wikimedia.org/show_bug.cgi?id=61163 == Tuesday == MediaWiki upgrades * group1 to 1.23wmf16: All non-Wikipedia sites (Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites) * see also: ** https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap#Schedule_for_the_depl… ** https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf16 == Wednesday == The new search cluster will be upgraded (to ElasticSearch 1.0.1). * This will begin at 0:00 UTC March 6th/4pm Pacific March 5th and will take a few hours to complete. * All wikis currently using the new search (CirrusSearch) will be temporarily switched back to the old serach (lsearchd) * You shouldn't see much of a change in search behavior (CirrusSearch is mostly feature parity to lsearchd) if your wiki is on new search, but to see a list of wikis that currently have CirrusSearch enabled (and in what way: Beta Feature or Primary), see: ** https://www.mediawiki.org/wiki/Search#Wikis == Thursday == MediaWiki upgrades * group2 to 1.23wmf16 (all Wikipedias) * group0 to 1.23wmf17 (test/test2/testwikidata/mediawiki) As always, questions welcome, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

2 1

Jump to page:

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