Wikitech-l September 2017

wikitech-l@lists.wikimedia.org

90 participants
76 discussions

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 27 Jun '24

27 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

Research FAQ gets a facelift
by Dario Taraborelli 25 Jun '24

25 Jun '24

We just released a new version of Research:FAQ on Meta [1], significantly expanded and updated, to make our processes at WMF more transparent and to meet an explicit FDC request to clarify the role and responsibilities of individual teams involved in research across the organization. The previous version – written from the perspective of the (now inactive) Research:Committee, and mostly obsolete since the release of WMF's open access policy [2] – can still be found here [3]. Comments and bold edits to the new version of the document are welcome. For any question or concern, you can drop me a line or ping my username on-wiki. Thanks, Dario [1] https://meta.wikimedia.org/wiki/Research:FAQ [2] https://wikimediafoundation.org/wiki/Open_access_policy [3] https://meta.wikimedia.org/w/index.php?title=Research:FAQ&oldid=15176953 *Dario Taraborelli *Head of Research, Wikimedia Foundation wikimediafoundation.org • nitens.org • @readermeter <http://twitter.com/readermeter>

2 1

bluejeans
by Jeremy Baron 22 Feb '23

22 Feb '23

Hi, On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote: > We will be holding this brownbag in 25 minutes. The Bluejeans link has > changed: > > https://bluejeans.com/396234560 I'm not familiar with bluejeans and maybe have missed a transition because I wasn't paying enough attention. is this some kind of experiment? have all meetings transitioned to this service? anyway, my immediate question at the moment is how do you join without sharing your microphone and camera? am I correct thinking that this is an entirely proprietary stack that's neither gratis nor libre and has no on-premise (not cloud) hosting option? are we paying for this? -Jeremy

9 16

New DB_REPLICA constant; DB_SLAVE deprecated
by Aaron Schulz 04 Jul '20

04 Jul '20

As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA instead of DB_SLAVE, with the old constant left as an alias. This is part of a string of commits that cleaned up the mixed use of "replica" and "slave" by sticking to the former. Extensions have not been mass converted. Please use the new constant in any new code. The word "replica" is a bit more indicative of a broader range of DB setups*, is used by a range of large companies**, and is more neutral in connotations. Drupal and Django made similar updates (even replacing the word "master"): * https://www.drupal.org/node/2275877 * https://github.com/django/django/pull/2692/files & https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a023… I don't plan on doing anything to DB_MASTER, since it seems fine by itself, like "master copy", "master tape" or "master key". This is analogous to a master RDBMs database. Even multi-master RDBMs systems tend to have a stronger consistency than classic RDBMs slave servers, and present themselves as one logical "master" or "authoritative" copy. Even in it's personified form, a "master" database can readily be thought of as analogous to "controller", "governer", "ruler", lead "officer", or such.** * clusters using two-phase commit, galera using certification-based replication, multi-master circular replication, ect... ** https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_… *** http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium… -- -Aaron

4 3

Roadmap for CX?
by Strainu 06 Sep '18

06 Sep '18

Following the recent outage, we've had a new series of complaints about the lack of improvements in CX, especially related to server-side activities like saving/publishing pages. Now, I know the team is involved in a long-term effort to merge the editor with the VE, but is there an end in sight for that effort? Can I tell people who ask "look, 6 more months then we'll have a much better translation tool"? Is there a publicly available roadmap for this project and more generally, for CX? Thanks, Strainu

5 8

Can we drop revision hashes (rev_sha1)?
by Daniel Kinzler 07 Dec '17

07 Dec '17

Hi all! I'm working on the database schema for Multi-Content-Revisions (MCR) <https://www.mediawiki.org/wiki/Multi-Content_Revisions/Database_Schema> and I'd like to get rid of the rev_sha1 field: Maintaining revision hashes (the rev_sha1 field) is expensive, and becomes more expensive with MCR. With multiple content objects per revision, we need to track the hash for each slot, and then re-calculate the sha1 for each revision. That's expensive especially in terms of bytes-per-database-row, which impacts query performance. So, what do we need the rev_sha1 field for? As far as I know, nothing in core uses it, and I'm not aware of any extension using it either. It seems to be used primarily in offline analysis for detecting (manual) reverts by looking for revisions with the same hash. Is that reason enough for dragging all the hashes around the database with every revision update? Or can we just compute the hashes on the fly for the offline analysis? Computing hashes is slow since the content needs to be loaded first, but it would only have to be done for pairs of revisions of the same page with the same size, which should be a pretty good optimization. Also, I believe Roan is currently looking for a better mechanism for tracking all kinds of reverts directly. So, can we drop rev_sha1? -- Daniel Kinzler Principal Platform Engineer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.

16 29

Upcoming holidays/events and their impact on the deployment schedule
by Greg Grossmeier 06 Nov '17

06 Nov '17

Hello all, It's that time of year again where the density of holidays increases and at the same time our plans for fundraising also increase. Per our usual practice we will be not doing deployments at various points in the next few months. Here's the full outline: Reminder for all on we did last year: * No MW train the week of Thanksgiving (but SWAT deploys were open for high-priority things). * No deploys (at all) the last two weeks of December. People were happy with this. * The first week of January was normal (minus Monday being Jan 2nd, our observed New Year's Day holiday) deployment wise. * The second week was weird due to Dev Summit/All Hands: No MediaWiki train, only SWATs as needed on Mon/Tues/Wed. No SWATs/deploys during All Hands. I imagine we'll do similarly. In that case (looking at the calendar....) * No MW train the week of Thanksgiving (Nov 20th), SWATs open for high priority things * No deploys weeks of Dec 18th and 25th (last two weeks) * Normal week week of Jan 1st (minus no deploys that Monday) * The Dev Summit and WMF All Hands is the week of January 22nd, so that will be a "No Train but SWATs OK on Mon/Tues/Wed" week. * The following week (week of January 29th) the Release Engineering team will be on an offsite, so a week of "No Train, but SWATs and service deploys OK". This is now on-wiki at: https://wikitech.wikimedia.org/wiki/Deployments#Upcoming Best, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | Release Team Manager A18D 1138 8E47 FAC8 1C7D |

1 1

Selenium Ruby framework deprecation
by Željko Filipin 30 Oct '17

30 Oct '17

As announced in April[0], we are replacing Selenium tests written in Ruby with tests in Node.js. Now is the last responsible moment to make the move. There will be two more reminders, in September and October. In the meantime, only critical problems will be resolved in the Ruby stack. After October we will no longer maintain it. You can follow task T139740[1] for more information. Extensive documentation is available at mediawiki.org[2]. If you need help with the migration, I am available for pairing and code review (zfilipin in Gerrit, zeljkof in #wikimedia-releng). Željko Filipin -- 0: https://lists.wikimedia.org/pipermail/wikitech-l/2017-April/087888.html 1: https://phabricator.wikimedia.org/T139740 2: https://www.mediawiki.org/wiki/Selenium/Node.js

1 2

Upgrade of QUnit from 1.x to 2.x is underway
by Krinkle 24 Oct '17

24 Oct '17

TL;DR: MediaWiki core is upgrading its version of QUnit from 1.x to 2.x. This means extensions or skins with QUnit tests must now be compatible with 2.x. See https://phabricator.wikimedia.org/T170515 and https://qunitjs.com/upgrade-guide-2.x/. Hi all, ### Deprecated API In 2014, QUnit started to overhaul its API, to be more robust and better support async workflows. The most notable change was the removal of global and static functions, in favour of more contextual methods. The first part of this released in 1.15, and more was gradually introduced in later releases. The vast majority of our codebases are already using the new interfaces. In fact, the vast majority of our QUnit tests were written after 2014 and never used the old interfaces in the first place. For a short list of removed functions, see https://phabricator.wikimedia.org/T170515. If you find a QUnit Jenkins job for a MediaWiki extension or skin repo starts failing, it is most likely due to this. Look for errors such as "QUnit.start undefined", "test.callback is not a function", "QUnit.asyncTest is undefined", and "QUnit.push is undefined", There are also some methods that have been deprecated over the past few years. These still work in QUnit 2. Please take a moment to familiarise yourself with the renamed methods and new methods. Doing so will avoid confusion when reading new code that uses them. See https://qunitjs.com/upgrade-guide-2.x/. ### New features The 'setup' and 'teardown' module hooks are now called 'beforeEach' and 'afterEach'. The old names still work, but the new names clarify that these hooks are run for each QUnit.test(). QUnit 2.0 also adds new 'before' and 'after' hooks, which run only once per module. This is somewhat analogous to use of setUpBeforeClass() in PHPUnit. Since QUnit 1.16, QUnit.test() supports returning a Promise from the test callback. This automatically attaches an assert.async() handler and waits for the promise to complete. It also asserts that the Promise will be resolved, and fails the test if rejected. This helps avoid a common pitfal where a test could timeout when forgetting to attach a promise.fail() handler. ## Upgrade The version used on Special:JavaScriptTest has already been upgraded. – https://gerrit.wikimedia.org/r/365757. The copy used for command-line usage (grunt-karma) and Jenkins will be upgraded by https://gerrit.wikimedia.org/r/367838 -- Timo

1 1

Disabling Messaging Fallbacks for Language Analysis
by Trey Jones 24 Oct '17

24 Oct '17

SUMMARY: The Search Platform team (formerly part of Discovery) is planning to fix a long-standing search bug on many wiki projects by disabling the code in CirrusSearch that re-uses the “fallback” languages (which are specified for user interface or system messages) for the language analysis modules (which are used to index words in search). Deployment is planned to start the week of October 9, 2017. Messaging fallbacks specify what language to show a message in when there is no message available in the language of a given wiki. A language analysis module is language-specific software that processes text to improve searching—so that, for example, searching for a given word will find related forms of that word, like "hope, hopes, hoping, hoped" or "resume, resumé, résumé" on English-language wikis. Fallback languages for system messages make sense for historical and cultural reasons—a reader of the Chechen Wikipedia is more likely to understand a user interface or system message in Russian than in French, Greek, Hindi, Italian, or Japanese—but the fallbacks don't necessarily make any linguistic sense. Chechen and Russian, for example, are from unrelated language families; while the languages have undoubtedly influenced one another, their grammars are completed different. We will deploy the software change that disables using messaging fallbacks for language analysis fallbacks in about two weeks (targeting the week of October 9, 2017), with any cross-language analysis exceptions explicitly configured in a new manner. Changes will not immediately happen to all affected wikis because each wiki in each language will need to be re-indexed, which is a separate process that takes time. There may also be other delays caused by Elasticsearch upgrades or other changes that need immediate attention. You can also track progress of the tasks on Phabricator[1] or read more, see examples, and get the full list of languages affected on MediaWiki.[2] [1] https://phabricator.wikimedia.org/T147959 [2] https://www.mediawiki.org/wiki/Wikimedia_Discovery/Disabling_Messaging_Fall… Trey Jones Sr. Software Engineer, Search Platform Wikimedia Foundation

1 1

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 September 2017