Wikitech-l June 2020

wikitech-l@lists.wikimedia.org

66 participants
77 discussions

(Low prio) Do we still need AtEase?
by Krinkle 09 Sep '20

09 Sep '20

It does the same as the @ operator, except that it takes care to prevent a very bad bug that existed before PHP 7. Details at https://phabricator.wikimedia.org/T253461 If there are other issues or benefits, please write them on the task. The overhead of AtEase is prerty minor, so really any benefit at all is likely to tip the balance toward keeping it. But, in the event that there isn't any, then perhaps we should slowly phase it out. Best, -- Timo

1 1

Logo of mediawiki
by Amir Sarabadani 04 Sep '20

04 Sep '20

Hello, The current logo of MediaWiki was adapted slightly more than fifteen years ago and hasn’t changed since. This logo despite having the nice concept of sunflower, is old. The sunflower represents the diversity, the constant growth and also the wildness. Among its biggest issues I can point out that it’s a bitmap picture so it’s unusable in large sizes (like large posters) and it’s too realistic making it unusable in small sizes. Most, virtually all, software products use a simpler and more abstract form. For example, docker, kubernetes, Ubuntu, VueJs, React, Apache Kafka, and many more. It’s a good time for MediaWiki to follow suit. My request is for changing the logo of MediaWiki and I have no plans or interest in changing logo of any other project. Please show your support, oppose or your comments in the discussion page. You can also add more suggestions. The discussion page: https://www.mediawiki.org/wiki/Project:Proposal_for_changing_logo_of_mediaw… Best -- Amir (he/him)

1 3

realtime notifications disabled in Phabricator
by Daniel Zahn 17 Aug '20

17 Aug '20

Phabricator users, this is to let you know that the "aphlict" service has been disabled on Phabricator (for now) because it caused stability issues. This means you will not get realtime (pop-up) notifications on Phabricator. (If you had those enabled in the first place). Regular notifications (that do not pop-up) and emails are not affected by this. https://phabricator.wikimedia.org/T238593 -- Daniel Zahn <dzahn(a)wikimedia.org> Operations Engineer

8 15

MediaWiki 1.35 Branch Cut and Release
by Cindy Cicalese 09 Jul '20

09 Jul '20

On March 30, we announced that we were temporarily pushing back the release of MediaWiki 1.35 due to uncertainty resulting from the COVID-19 pandemic. We are now ready to begin the process of moving forward with the release. The first step is cutting the release branch, REL1_35, which will occur on Monday, July 13. We will then be in "pencils down" mode: developers will stop targeting MediaWiki 1.35 for new features. Instead, any new features would continue to be applied to master and would target MediaWiki 1.36 or later. The only work that would continue towards MediaWIki 1.35 would be blockers - critical bug fixes or features close to completion that need to make it into the release. This would happen by merging those patches into master and then backporting them to the REL1_35 branch. We anticipate that MediaWiki 1.35 will be released at the beginning of August. We appreciate your patience in these difficult times. Wishing you safety and health, Cindy

3 2

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

Skins: Deprecation of various hooks and introducing SkinMustache
by Jon Robson 01 Jul '20

01 Jul '20

Hello, TLDR: The following hooks are deprecated in 1.35: SkinTemplateBuildNavUrlsNav_urlsAfterPermalink, SkinTemplatePreventOtherActiveTabs, SkinTemplateTabAction, BaseTemplateAfterPortlet, SkinTemplateToolboxEnd, BaseTemplateToolbox, SkinTemplateOutputPageBeforeExe. The longer version: As part of the desktop improvements project <http://mediawiki.org/wiki/Desktop%20improvements> we've been making some exciting changes in MediaWiki's skin architecture. This has involved migrating away from the BaseTemplate PHP class to Mustache as the render engine for Vector. In 1.36, the Vector skin plans to use the new SkinMustache class <https://github.com/wikimedia/mediawiki/blob/master/includes/skins/SkinMusta…> and do away with the BaseTemplate class. This meant that we had to deprecate various BaseTemplate hooks, providing more suitable generic alternatives in the shared Skin.php layer. We also took the opportunity to reduce the number of active hooks that operate in the skin layer for developer sanity. >From now on it is intended that any skin modifications are done *prior *to rendering. The renderer whether it is BaseTemplate or SkinMustache will simply render the data that's been provided. As a result of this I have various changes to report! The *SidebarBeforeOutput <https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Hooks/SidebarBefor…> *hook now can be used to modify the toolbox and languages portals. Previously these sidebar menus had their own bespoke hooks. The SkinTemplateBuildNavUrlsNav_urlsAfterPermalink hook <https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateBuildNavUrlsNav_url…> is deprecated and can be replaced with the new and improved SidebarBeforeOutput hook. The SkinTemplatePreventOtherActiveTabs and SkinTemplateTabAction hooks <https://phabricator.wikimedia.org/T253814>were seldom used and replaced with SkinTemplateNavigation::Universal . All BaseTemplate hooks should now be considered deprecated per T253809 <https://phabricator.wikimedia.org/T253809>. - BaseTemplateAfterPortlet <https://www.mediawiki.org/wiki/Manual:Hooks/BaseTemplateAfterPortlet> is replaced with the template-rendering agnostic SkinAfterPortlet <https://www.mediawiki.org/wiki/Manual:Hooks/SkinAfterPortlet> - SkinTemplateToolboxEnd <https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateToolboxEnd>is replaced with the new and improved version of SidebarBeforeOutput - BaseTemplateToolbox <https://www.mediawiki.org/wiki/Manual:Hooks/BaseTemplateToolbox> is replaced with the new and improved version of SidebarBeforeOutput Finally a big one: The SkinTemplateOutputPageBeforeExec hook is now deprecated <https://phabricator.wikimedia.org/T60137>. Previously this hook could do a lot of things and often in ways that were hard to reason with. For example, previously this hook was used alongside other hooks to add items to the footer and to override skin internals to display portals that were normally hidden. We looked through all the use cases for this hook and are confident we've caught the most confident use cases. Migration depends on what it was previously used for but are documented on mediawiki.org <https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateOutputPageBeforeExe…>. It's possible there are other use cases, we missed and if so we plan to cover those during the 1.36 release. If you are an extension developer and have any questions about migration please feel free to ping me on the associated Phabricator ticket or hook talk page, we will be happy to improve the documentation and help you find the right way to upgrade your code. As we go into 1.36 we plan to make changes that simplify MediaWiki skin development and make the ecosystem friendlier to frontend developers and make skins easier to maintain. In fact, in future, it will be possible to write skins without a single line of PHP. If you are excited or intrigued by these changes and want to get involved in the conversations I urge you to subscribe to our board. <https://phabricator.wikimedia.org/project/board/4795/> I'm particularly interested in hearing from developers who are keen to make skins in the new ecosystem. Your input and creativity would be much appreciated. Feel free to drop me a private mail or engage in open conversations. In addition to all the extension developers who helped review changes to their hook contracts, I would like to especially thank the following people for getting us to this landmark: Ammarpad, Timo, Volker and Mainframe98. I'd like to give a specific shout out for Ammarpad who has been a huge driving force here, preventing various bugs from occurring and swiftly responding to many of the unexpected regressions that we encountered during this work. We couldn't have done this without you! Thanks for reading! Jon

2 1

Gerrit upgrade on Saturday, 27th of June
by Christian Aistleitner 01 Jul '20

01 Jul '20

[Apologies for cross-posting] Hi, TL;DR: We will take our Gerrit instance at gerrit.wikimeda.org offline on Saturday, 27th of June from 17:00--22:00 UTC (hopefully much shorter) to upgrade to the latest Gerrit v3.2.2. (10:00--15:00 San Francisco time, and 19:00--24:00 Central European time) --------------------------------- We're currently running Gerrit v2.15, which is no longer supported and we will upgrade to Gerrit v3.2 on Saturday 27th of June. This new version brings lots of improvements. The most noticeable change is probably the UI overhaul. The (default) "old UI" gets removed and the "new UI" has been completely revamped. It's much more modern looking and easier to use. And it also became far more usable on mobile phones. But the new version of course also comes with fixes and additions around the ssh interface, and the HTTP API. Since this is such a big upgrade, we want to give you a chance to look at it beforehand. You can test at https://gerrit-test.wikimedia.org/ It holds a copy of our Gerrit data as of 15th of June, and it runs the new Gerrit v3.2.2. We'll keep tuning things there during this week, so it might get an occasional restart. But look around and test the new UI, the HTTP API, etc. If you run into issues or discover bugs, please open tickets in Phabricator and set the Gerrit 3.x upgrade task (T254158) as parent. Note that this test Gerrit instance is already hooked up with our Phabricator. If you upload / merge / abandon / etc changes with a `Bug: Tnnnn` footer, you'll get comments on the corresponding tasks in Gerrit. So please use our test task T775 for your experiments. As everything, also this upgrade comes with a few downsides: * The new UI no longer works on Internet Explorer (currently ~0.02% of Gerrit's web requests). Microsoft's Edge browser works though. So if you are still using Internet Explorer, please consider switching to a different browser. * Users of git-review need to use at least version 1.27 (released September 2018). Otherwise uploading changes will fail. * Your git should be at least version 2.2.0 (released November 2014) to take advantage of the new, much simpler commit-msg hook. Keeping my fingers crossed for a painless update, Christian with lots of helping hands from RelEng, and SRE

8 11

1.39.0-wmf.39 train is blocked (Flow/Sidebar issue)
by Antoine Musso 01 Jul '20

01 Jul '20

Hello, The 1.39.0-wmf.39 is blocked, immediately after deploying it to group0 wikis, Flow topics ended up being error pages. When browsing a topic page, there are two issues bubbling up in logstash: >From VectorTemplate->buildSidebar() * /srv/mediawiki/php-1.35.0-wmf.39/includes/language/Message.php:261 $key must be a string or an array >From Skin->buildSidebar / ElectronPdfServiceHooks::onSidebarBeforeOutput * /srv/mediawiki/php-1.35.0-wmf.39/extensions/ElectronPdfService/src/ElectronPdfServiceHooks.php:62 PHP Notice: Undefined index: print Which as I understand it causes an exception. The breaking bug is: https://phabricator.wikimedia.org/T256761 -- Antoine "hashar" Musso Release Engineering

1 1

Upcoming Search Platform Office Hours—July 1st, 2020
by Trey Jones 30 Jun '20

30 Jun '20

The Search Platform Team <https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> usually holds office hours the first Wednesday of each month. Come talk to us about anything related to Wikimedia search! Feel free to add your items to the Etherpad Agenda for the next meeting. Details for our next meeting: Date: Wednesday, July 1st, 2020 Time: 15:00-16:00 GMT / 08:00-09:00 PDT / 11:00-12:00 EDT / 17:00-18:00 CEST Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours Google Meet link: https://meet.google.com/vyc-jvgq-dww Join by phone in the US: +1 786-701-6904 PIN: 262 122 849# Hope to talk to you in a week! —Trey Trey Jones Sr. Software Engineer, Search Platform Wikimedia Foundation UTC-4 / EDT

1 1

Debian Jessie base Wikimedia container image being phased out
by Alexandros Kosiaris 30 Jun '20

30 Jun '20

Hello everyone, In the interest of proceeding with the deprecation of Jessie in our infrastructure, SRE ServiceOps will stop maintaining and eventually remove the base Debian Jessie OCI container image[1], also known as wikimedia-jessie, from our docker registry. If you rely on this image in any way, you are strongly urged to move to our Debian Stretch or Buster images, which will continue to be maintained for some time (for more information see https://wikitech.wikimedia.org/wiki/Operating_system_upgrade_policy). A tentative timeline follows: * 2020-07-02. https://gerrit.wikimedia.org/r/c/operations/puppet/+/587529 will be merged. This will mean the image will no longer be receiving any kind of updates but will still be possible to be pulled from the registry. Workflows are not expected to break. * 2020-08-03. Removal of all the image tags and versions of the above image will happen. That will mean that the image will no longer be able to be pulled from the registry. If you have any workflows that rely on pulling this image from the registry, they are expected to break on this date. Images that have already been published and are based on the Jessie image however will not be touched and will still be pullable. If you have a workflow that will break after the 2020-08-03 mark and are unable to alter it, please reach out to us. Following the above, we will also investigate whether removing image versions and tags that depend on the removed image makes sense. Note that this is the first time we remove a base image from our registry and as such we are building knowledge and experience around this. [1] https://tools.wmflabs.org/dockerregistry/wikimedia-jessie/tags/ Regards, -- Alexandros Kosiaris Principal Site Reliability Engineer Wikimedia Foundation

1 0

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 June 2020