Wikitech-l February 2015

wikitech-l@lists.wikimedia.org

134 participants
140 discussions

server-side HTML templating now live in core
by Ryan Kaldari 26 Feb '15

26 Feb '15

After 14 months of discussion, HTML templating is now live in core MediaWiki. Currently only the server-side implementation has been merged. A client-side implementation has also been submitted, but is stalled in Gerrit (https://gerrit.wikimedia.org/r/#/c/180647/). You can now use Mustache templates in your extensions and core code by calling TemplateParser->processTemplate(). Full documentation can be found at https://www.mediawiki.org/wiki/Manual:HTML_templates. There are three main impetuses for this new feature: 1. Improving the sanity and readability of MediaWiki code. Ideally, our PHP code should have little or no HTML in it. We should strive to keep our PHP interfaces high-level and with clear separation of concerns. We are a long way from conforming to anything like an MVC pattern, but this brings us one step closer to being able to achieve that. The work on OOjs and related interfaces is another important component of this. 2. Standardizing our templating implementations. There are currently six different HTML templating implementations in various MediaWiki extensions.[1] Hopefully, we can now reduce that number. 3. Moving MobileFrontend into core. We are also a long way away from achieving this goal, but now one step closer. MobileFrontend relies heavily on HTML templating, so having this feature in core is a pre-requisite to moving more MobileFrontend features over. I know there is still disagreement about the specific implementation details of this feature (such as the choice of Mustache), but this is just the first iteration of this feature and I hope we can work together to revise and improve it further. 1. https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library… Ryan Kaldari

3 2

Reminder: VisualEditor weekly triage meetings – 2015-02-25/26
by James Forrester 25 Feb '15

25 Feb '15

As a reminder, this week's VisualEditor triage meeting will be at 00 <http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150225T16&p1=224…> :00 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150225T16&p1=224…> on Thursday 26 February ( 16 :00 PST on Wednesday 25 February) – that's in approximately 5 hours' time. Joining instructions are on mw:Talk:VisualEditor/Portal <https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal#How_to_join_the_tri…> . Hope to see many of you there. Yours, -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

1 0

"Needs Volunteer" priority field value in Phabricator
by Andre Klapper 25 Feb '15

25 Feb '15

Apparently the idea to rename the Priority field value from "Lowest" in Bugzilla to "Needs Volunteer" in Phabricator created more confusion than expected. I am sorry for that - wasn't intended. To fix that, there are two questions that welcome input in https://phabricator.wikimedia.org/T78617 : 1) Our Phabricator currently offers six levels of prioritization. See https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_leve… Do project maintainers / devs really feel a need for planning to differentiate between "low" priority and one level below that? Or could we reduce our six levels with five levels? 2) If there is a need for a level below "low": Let's rename "Needs Volunteer" back to "Lowest" (Looking at the proposed names in T78617, "Lowest" seems to be the least confusing term / smallest evil.) If you feel like helping make a decision by adding some *additional* arguments based on your experience, please raise your voice in T78617 after reading the existing comments and arguments in that task. Thank you for your help! andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

5 6

Wikimedia Hackathon travel sponsorship
by Quim Gil 25 Feb '15

25 Feb '15

Hi, we are hoping to open registration to the Wikimedia Hackathon in Lyon next week. Those of you relying on travel sponsorship can start preparing your requests already now: # Familiarize yourself with the goals of the hackathon: https://www.mediawiki.org/wiki/Hackathons#The_Wikimedia_Hackathon_model # Join or propose a demo-able project in Phabricator: https://phabricator.wikimedia.org/tag/wikimedia-hackathon-2015/ # Find a hackathon buddy in the Wikimedia communities or related projects out there: https://www.mediawiki.org/wiki/Lyon_Hackathon_2015/Buddies Here you have a draft form to get an idea of what questions you will be asked: http://goo.gl/forms/MPzx8q7BBz (not a real form; data submitted will be ignored and deleted) Your feedback about the process is welcome, especially in the related Phabricator task: https://phabricator.wikimedia.org/T88406 -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Partial (but dramatic) labs outage on Tuesday: 2015-02-24 1500UTC-1800UTC
by Andrew Bogott 24 Feb '15

24 Feb '15

It is with a heavy heart that I must share the news of an upcoming Labs maintenance window. The labs NFS store (which you probably know as /data/project) is filling up rapidly and we need to add more drives. By weird coincidence the actual physical space for that server in the datacenter is ALSO filling up, so Chris Johnson has graciously agreed to spend his day re-shuffling servers in order to make space for the new diskshelf. This involves lots of unplugging and replugging and amounts to the fact that the NFS server will need to be turned off for several hours. During this window Chris will take care of another long-deferred maintenance task -- he's putting more RAM into the labs puppet master, virt1000. What will break: - Shared storage for all labs and tools instances. That includes volumes like /data/project, /public/dumps, /data/scratch, /home - Logins to all instances running ubuntu Precise. (Trusty hosts will /probably/ still support logins.) - Login to wikitech and manipulation of instances. What won't break: - Labs instances will continue to run - Tasks running on instances will continue to run; those that don't rely on shared storage should be fine. - Web proxies should keep working, if the services they support aren't relying on shared storage. What will get better: - More storage space! - Fewer problems with dumps filling up NFS (which is basically the same as 'more storage space'. - More reliable puppet runs and fewer outages with miscellaneous OpenStack services (which also run on virt1000) I apologize in advance for this downtime. Don't hesitate to contact me or Coren either here or on IRC with advice about how to harden your tool against this upcoming outage. We will also be available on IRC during and after the outage to help revive things that are angry about the timeouts. -Andrew

2 2

New process for Gerrit repository ownership requests
by Quim Gil 24 Feb '15

24 Feb '15

The on-wiki process to request ownership of Gerrit repository has been moved to Phabricator. We hope this change will contribute to a faster processing of requests, not because Phabricator is intrinsically magic, but because you can now associate requests to relevant Phabricator projects and CC existing repo owners to your requests. https://www.mediawiki.org/wiki/Gerrit/Project_ownership https://phabricator.wikimedia.org/tag/repository-ownership-approvers/ These are the people who can approve repository ownership: https://phabricator.wikimedia.org/project/members/1076/. Ideally all of you would watch this project to receive notifications as soon as new requests are submitted... instead of leaving almost all the work to Chad and QChris. By the way, there seems to be an open request: Replacing mwalker with cscott for the OCG repositories https://phabricator.wikimedia.org/T90585 PS: this migration has been discussed at https://phabricator.wikimedia.org/T86639 -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

2 2

Announcing service-runner, a startup module / supervisor for node services
by Gabriel Wicke 24 Feb '15

24 Feb '15

Hi folks, in our quest to simplify the creation of production-quality services we have recently made some modest progress with a service-runner module [1] and an early service-template-node prototype [2]. The latter deserves its own discussion (and is at a very early stage), so I'm focusing on service-runner in this thread. Service-runner [1] is a small module that we moved out of restbase. It generalizes some simple start-up, monitoring and supervision facilities that we refined while building services like Parsoid, Mathoid or RESTBase: - commandline option parsing & yaml config loading (with a standard format) - worker pool management using the cluster module; graceful restarts - logging via gelf to logstash, with option to configure other backends - generic metric reporting (txstatsd, statsd or simple logging for development) - general worker monitoring & debugging: V8 heap metrics & limiting, support for heap dumps For small (third party) installs with limited memory, we also added the capability to cleanly run multiple services in a single process. The uniform way to run and configure services provided by service-runner should let us create a shared puppet module to manage most of the per-service tasks [3]. Another possibility is to automatically build packages for these services [4], which can help to distribute these services to third-party users. So, please have a look & let us know what you are missing / would like to see. There is a service-runner tag on phabricator [5] that we can use to track specific tasks. Thanks, Gabriel [1]: https://github.com/wikimedia/service-runner [2]: https://github.com/wikimedia/service-template-node [3]: https://phabricator.wikimedia.org/T89901 [4]: https://phabricator.wikimedia.org/T89900 [5]: https://phabricator.wikimedia.org/tag/service-runner/

6 8

Re: [Wikitech-l] If you hear about 'hackathon buddies'...
by Quim Gil 24 Feb '15

24 Feb '15

If you are looking for a Wikimania Hackathon buddy, check https://wikimania2015.wikimedia.org/wiki/Hackathon/Buddies On Thu, Feb 19, 2015 at 3:57 PM, Quim Gil <qgil(a)wikimedia.org> wrote: > Yesterday we opened the travel request process for Wikimedia Foundation > employees in Engineering and Product willing to participate at the > Wikimedia Hackathon or Wikimania. There is no public link, but you can > follow this task at https://phabricator.wikimedia.org/T89355 > > In this process, we are asking WMF employees to find a hackathon buddy > with the sole requirement of not being another WMF employee. In fact, in > the registration for the hackathons we will request the same to all > participants. > > https://www.mediawiki.org/wiki/Hackathons#Pairing_buddies > > This means that non-WMF contributors might receive a request from a WMF > employee to be hackathon buddies. This also means that if you are planning > to participate in any of these events (and especially if you plan to > request travel sponsorship to Lyon) you will be encouraged to find a buddy > as well. > > It's going to be fun. :) And no worries, we will help making connections > to whoever needs that help. > -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Global user pages deployed to all wikis
by Legoktm 23 Feb '15

23 Feb '15

Hello! Global user pages have now been deployed to all public wikis for users with CentralAuth accounts. Documentation on the feature is available at mediawiki.org[1], and if you notice any bugs please file them in Phabricator[2]. Thanks to all the people who helped with the creation and deployment (incomplete, and in no particular order): Jack Phoenix & ShoutWiki, Isarra, MZMcBride, Nemo, Quiddity, Aaron S, Matt F, James F, and everyone who helped with testing it while it was in beta. [1] https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage [2] https://phabricator.wikimedia.org/maniphest/task/create/?projects=PHID-PROJ…

25 39

Increase min mysql version to 5.0.3
by Brian Wolff 23 Feb '15

23 Feb '15

Currently the min mysql version we require is 5.0.2. In order to fix T6715 [2], I'd like to bump it to 5.0.3. This would allow us to have varchar fields larger than 255. Anyone have any objections? 5.0.3 was released in march 2005 (8 years ago!), so this is hardly bleeding edge. As far as I can tell, Wikiapiry says this would affect no wikis [1] [0] https://phabricator.wikimedia.org/T6715 [1] https://wikiapiary.com/w/index.php?title=Special%3ASearchByProperty&propert… -- bawolff

1 0

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

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