Wikitech-l January 2014

wikitech-l@lists.wikimedia.org

136 participants
118 discussions

Request Queue for Gerrit/Git
by Ty Atkinson 26 Jan '14

26 Jan '14

Hello all, I am User:TyA. I noticed on the [[Annoying large bugs]] page there was a request for a Request Queue and I'm interested in working on that. I have some basic ideas of how to lay it out, however I'd like to hear other's opinions on it as well. I'm also curious if it is still needed. My current plan is to have 2 special pages, one for the requesting and the other for seeing the queue/examining the submitted items. I currently have a rough draft of the Requesting form complete, [ http://i.imgur.com/zRAAyvh.png screenshot]. However before going too much further, I wanted to get some feedback on whether I'm collecting enough info, or maybe not enough. My plan for the actual queue page is to have it create a table or list that will give the current status of the request as well as the requester, the submitted date, and the project name. The page will also accept /id subpages to load up information about a certain request so that it can be marked as done, not done, or needs more info. Thanks

3 2

help activists use our tech: Allied Media Conference
by Sumana Harihareswara 26 Jan '14

26 Jan '14

http://alliedmedia.org/news/2014/01/13/propose-session-amc2014 "The Allied Media Conference <https://amc.alliedmedia.org/> is a collaborative laboratory of media-based organizing strategies for transforming our world, held every Summer in Detroit." I'd love for us to propose some sessions to help people learn about and use Magnus's query tools, set up Wiki Loves Foo campaigns, and despam and rev up their MediaWiki installations with multimedia. The deadline is March 1, 2014. AMC2014 will be June 19-22, 2014 in Detroit, Michigan, USA. Volunteers: if your session gets accepted, you can get your trip paid for by WMF: https://meta.wikimedia.org/wiki/Grants:TPS Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

1 0

Bugzilla Weekly Report
by reporter 26 Jan '14

26 Jan '14

MediaWiki Bugzilla Report for January 20, 2014 - January 27, 2014 Status changes this week Reports changed/set to UNCONFIRMED: 7 Reports changed/set to NEW : 30 Reports changed/set to ASSIGNED : 36 Reports changed/set to REOPENED : 11 Reports changed/set to PATCH_TO_RE: 66 Reports changed/set to RESOLVED : 157 Reports changed/set to VERIFIED : 20 Total reports still open : 13739 Total bugs still open : 8006 Total non-lowest prio. bugs still open: 7797 Total enhancements still open : 5733 Reports created this week: 211 Resolutions for the week: Reports marked FIXED : 112 Reports marked DUPLICATE : 15 Reports marked INVALID : 10 Reports marked WORKSFORME: 15 Reports marked WONTFIX : 9 Specific Product/Component Resolutions & User Metrics Created reports per component VisualEditor Editing Tools 13 Wikimedia Site requests 11 MediaWiki extensions TimedMediaHandler 9 MediaWiki extensions WikidataRepo 9 Wikimedia General/Unknown 9 Created reports per product MediaWiki extensions 85 Wikimedia 38 MediaWiki 34 VisualEditor 24 Analytics 6 Top 5 bug report closers jforrester [AT] wikimedia.org 21 lydia.pintscher [AT] wikimedia15 jrobson [AT] wikimedia.org 11 esanders [AT] wikimedia.org 10 tomasz [AT] twkozlowski.net 8 Most urgent open issues Product | Component | BugID | Priority | LastChange | Assignee | Summary -------------------------------------------------------------- Analytics | Tech communit | 57038 | Highest | 2013-12-23 | acs[AT]bitergia.com | Metrics about contributors with +2 pe MediaWiki ext | Diff | 58274 | Highest | 2014-01-22 | wikibugs-l[AT]lists. | Implement an order-aware MapDiffer MediaWiki ext | Echo | 53569 | Highest | 2014-01-23 | wikibugs-l[AT]lists. | [Regression] Echo: Sending 2 e-mails MediaWiki ext | Flow | 58016 | Highest | 2014-01-25 | wikibugs-l[AT]lists. | Flow: Suppression redacts the wrong u MediaWiki ext | Translate | 60306 | Highest | 2014-01-22 | ori[AT]wikimedia.org | TypeError: mw.uls is undefined on [[m MediaWiki ext | WikidataRepo | 58166 | Highest | 2013-12-09 | wikidata-bugs[AT]lis | label/description uniqueness constrai MediaWiki ext | WikidataRepo | 57918 | Highest | 2014-01-13 | wikidata-bugs[AT]lis | show diffs for sorting changes MediaWiki ext | WikidataRepo | 52385 | Highest | 2014-01-16 | wikidata-bugs[AT]lis | Query by one property and one value ( MediaWiki ext | WikidataRepo | 60127 | Highest | 2014-01-17 | wikidata-bugs[AT]lis | Implement DB schema for query indexes VisualEditor | Data Model | 60117 | Highest | 2014-01-25 | esanders[AT]wikimedi | VisualEditor: Copying references is c VisualEditor | Editing Tools | 50768 | Highest | 2014-01-22 | rmoen[AT]wikimedia.o | VisualEditor: Better reference UI for VisualEditor | MediaWiki int | 48429 | Highest | 2014-01-21 | krinklemail[AT]gmail | VisualEditor: Support editing of sect Wikimedia | Apache config | 31369 | Highest | 2014-01-20 | bugzilla+org.wikimed | Non-canonical HTTPS URLs quietly redi Wikimedia | General/Unkno | 49189 | Highest | 2014-01-16 | springle[AT]wikimedi | New fields: ar_id, el_id. Wikimedia | Site requests | 60408 | Highest | 2014-01-26 | wikibugs-l[AT]lists. | Enable global AbuseFilters for all sm Wikimedia Lab | Infrastructur | 48501 | Highest | 2014-01-23 | greg[AT]wikimedia.or | beta: Get SSL certificates for *.{pro

1 0

RFC: assertion of pre- and postconditions
by Daniel Kinzler 24 Jan '14

24 Jan '14

RFC: https://www.mediawiki.org/wiki/Requests_for_comment/Assert This is a proposal for providing an alternative to PHP's assert() that allows for an simple and reliable way to check preconditions and postconditions in MediaWiki code. The background of this proposal is the reoccurring discussions about whether PHP's assert() can and should be used in MediaWiki code. Two relevant threads: http://www.gossamer-threads.com/lists/wiki/wikitech/275737 http://www.gossamer-threads.com/lists/wiki/wikitech/378676 The outcome appears to be that assertions are generally a good way to improve code quality but PHP's assert() is broken by design Following a suggestion by Tim Starling, I propose to create our own functions for assertions. -- daniel

1 0

Non-complicated way to display configuration for a given wiki?
by Tim Landscheidt 24 Jan '14

24 Jan '14

Hi, to test changes to operations/mediawiki-config, I'd like to display the settings for a given wiki. So far I figured out: | <?php | $IP = 'wmf-config'; | $cluster = 'pmtpa'; | require ('/home/tim/public_html/w/includes/SiteConfiguration.php'); | require ('wmf-config/wgConf.php'); | var_dump ($wgConf->getAll ([...])); However, all my creativity regarding parameters to getAll() only returned an empty array. What would be the parameters needed for example to get the settings for de.wikipedia.org? TIA, Tim

2 3

!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

hackathon in Israel - report
by Sumana Harihareswara 23 Jan '14

23 Jan '14

https://blog.wikimedia.org/2014/01/21/wikimedia-israel-winter-hackathon/ Thanks to the folks who put together this event! I would love to hear more about the "Python script to create a PowerPoint presentation directly from a Wikipedia article"... Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

2 1

MediaWiki-Vagrant can run MediaWiki under HHVM!
by Ori Livneh 23 Jan '14

23 Jan '14

Thanks to some fantastic work by Erik Bernhardson[0], MediaWiki-Vagrant can now run MediaWiki on HHVM. The setup runs HHVM behind Apache using FastCGI, which is a close match to how we think we'll be running it in production. It uses the 'hhvm-nightly' packages from Facebook, so you can test MediaWiki core and extensions against cutting-edge builds. To switch MediaWiki from PHP to HHVM, simply run 'vagrant enable-role hhvm', followed by 'vagrant provision'. To switch back to PHP, run 'vagrant disable-role hhvm' and reprovision. Please try it out and FILE BUGS for any issues you encounter. This includes not only provisioning failures (which should be reported under the MediaWiki-Vagrant product in Bugzilla) but also any instances of PHP code breaking under HHVM. There is now an 'hhvm' keyword in Bugzilla you can use to tag your report. Three cheers for Erik B., and for Facebook's Paul Tarjan, whose recent packaging work makes this possible. [0]: https://gerrit.wikimedia.org/r/#/c/105834/ --- Ori Livneh ori(a)wikimedia.org

3 3

Gallery of extensions for mediawiki.org
by Quim Gil 23 Jan '14

23 Jan '14

Following Rob's advice "If it doesn't make it to the mailing list it didn't happen." After a chat with Markus Glaser, Mark Hersberger, and Jared Zimmerman at the Architecture Summit, we have decided to create a wiki page to define the specifications of this project. Your ideas and feedback are welcome: https://www.mediawiki.org/wiki/MediaWiki/Gallery_of_extensions https://bugzilla.wikimedia.org/show_bug.cgi?id=46704 While we have no idea where the resources to develop this project will come from, we agree about its importance, and we think that defining a plan is the obvious first step. Markus & Mark will lead this discussion as part of their efforts improving MediaWiki as a product for third parties. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Module storage is coming
by Ori Livneh 23 Jan '14

23 Jan '14

The roll-out of 1.23wmf2 to your favorite Wikimedia wiki will inaugurate the era of ResourceLoader module storage -- an era which will be marked by terrifying and hilarious new bugs, intermittent client-side failures, and generally inexcusable disruptions to user experience. Sounds exciting? Read on! What is it? ----------- "Module storage" refers to the use of localStorage in ResourceLoader as an auxiliary to the browser cache. ResourceLoader, remember, is the MediaWiki subsystem that delivers JavaScript and CSS to your browser. One of its primary functions is to minimize the total number of network requests that your browser needs to make in order to render the page, and to make the remaining requests as slim as possible. One of the ways ResourceLoader does this is by making a list of all the different components your browser needs and then transmitting them in bulk. The downside of this approach is that a small update to MediaWiki's code, touching perhaps one or two components, will often force the browser to throw out (and re-retrieve) a bunch of unrelated modules that did not change and did not ostensibly need to be re-retrieved. This is because the browser cache operates on the level of network requests; it is not intelligent enough to decompose a request into its constituitive parts and to cache these parts separately from one another. Starting with the 1.23wmf2 branch, ResourceLoader will check if your browser implements localStorage, a mechanism for storing structure data. If it does, ResourceLoader will use it as an auxiliary cache, capable of versioning individual components. Why? ---- The primary goals are: * Destabalize MediaWiki's front-end code, by coupling it to an inconsistently-implemented and poorly-understood HTML5 API. * Make debugging fun again, by adding another layer of caching to MediaWiki. Yes!! However, as with all new features, unintended side-effects are possible. Specific concerns for module storage include the risk of making the network footprint of page loads smaller, resulting in improved latency. But seriously, -------------- * Module storage is enabled only if the underlying browser supports localStorage (~89% of browsers in use, according to <http://caniuse.com/#feat=namevalue-storage>). Users with older browsers will not see a benefit, but they will not suffer a penalty either. * Module storage may or may not improve site performance. We need to test it against a wide range of browsers and platforms to know for certain. If it doesn't improve performance, we'll blame it on you, your poor choice of browsers, and your uncooperative attitude, but then we'll scrap it. How can I test it? ------------------ Glad you asked! Module storage is enabled by default on the beta cluster, and on test & test2 wikis. The simplest way you can help is by being alert to to performance regressions and front-end code breakage. If you know how to use your browser's JavaScript console, you can get stats about module storage usage on the current page by checking the value of 'mw.loader.store.stats'. When the code is rolled out across the cluster, it will be disabled by default, but you will be able to opt-in by manually setting a cookie in your browser. I will follow up with the exact details. If module storage proves stable enough for production use, we'll seek to asses its utility by running a controlled study of some kind. If we can demonstrate that module storage leads to a significant improvement in performance, we'll enable by it default. --- Ori Livneh ori(a)wikimedia.org

27 57

← Newer
1
2
3
4
5
6
7
8
...
12
Older →

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 2014