Wikitech-l March 2021

wikitech-l@lists.wikimedia.org

58 participants
63 discussions

2021-03-17 Scrum of Scrums meeting notes
by Grace Gellerman 17 Mar '21

17 Mar '21

https://www.mediawiki.org/wiki/Scrum_of_scrums/2021-03-17#WMDE_Technical_Wi… = 2021-03-17 = == Callouts == * SRE ServiceOps upgrade of the k8s codfw kubernetes cluster completed. Traffic is being repooled, do reach out to us on T277191 if issues are observed. k8s eqiad cluster to probably follow next week. * SRE ServiceOps blocked on **Product Infrastructure on T274262 **Analytics on T274262 **Thanks to Product Infrastructure and PET for acting on the above task last week * RelEng: Developer satisfaction survey is live until 2021-03-24: https://forms.gle/xj2jNUcP7kmSgtwV8 * RelEng: When to use train vs backports quick guide: https://wikitech.wikimedia.org/wiki/Deployments/Train_vs_backport == Gerrit patches or GitHub Pull Requests for reviews or feedback == * === No updates === CommTech, AHT, Library === '''No notes provided''' === Editing, Growth, Parsing, Language, Inuka, Cloud Services, Performance, Quality & Test, Search Platform, Security, == SoS Meeting Bookkeeping == * Updates: == Product == === iOS native app === * Blocked by: N/A * Blocking: N/A * Thank yous: * Updates: Setting scope for next version. === Android native app === * Blocked by: N/A * Blocking: N/A * Thank yous: * Updates: New version out end of last week. Small updates, we're now releasing every 2 weeks. === Web === * Blocked by: * Blocking: * Thank yous: ** Michael Holloway of Product Infrastructure for diagnosing and fixing Readers Web's second (!!) duplicate EventLogging event bug, this time affecting the PrefUpdate schema: https://phabricator.wikimedia.org/T218835 * Updates: ** Still working on bolstering the UniversalLanguageSelector instrumentation: https://phabricator.wikimedia.org/T268504 and its subtasks ** … and the new Desktop Improvements language switcher treatment: https://phabricator.wikimedia.org/T256023 ** Investigating how to deliver the language switcher A/B test to everyone efficiently: https://phabricator.wikimedia.org/T275807 ** Deployed and then reverted an update to MobileFrontend's lead paragraph hoisting feature: https://phabricator.wikimedia.org/T262093 and https://phabricator.wikimedia.org/T277367 === Product Infrastructure === * Blocked by: * Blocking: ** SRE Service Ops on T274262 * Thank yous: ** From SRE Service Ops for working on chromium-render on T274262 * Updates: === Structured Data === * Blocked by: * Blocking: * Thank yous: * Updates: ** Wrapping up tasks needed before we make MediaSearch the default search UI on commons, including https://phabricator.wikimedia.org/T273879, which will switch the main search input to point to Special:MediaSearch (there will be a preference to switch this back to Special:Search available) ** Continuing to work on improved search profile ( https://phabricator.wikimedia.org/T271799) ** Continued discussions across teams regarding Structured Data Across Wikimedia (image recommendations API and structured content) ** Vue stuff: as part of our MediaSearch work (currently in WikibaseMediaInfo), we've added reusable Checkbox, Radio, and [in-progress] Dialog components === Abstract Wikipedia === * Blocked by: ** None? * Blocking: ** None? * Thank yous: * Updates: ** Continuing on phase gamma: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Phases ** The Wikifunctions logo concept vote has now closed; working with Legal and Comms on next steps: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Wikifunctions_logo_conce… === Vue.js === * Blocked by: * Blocking: * Thank yous: ** Everyone who helped push through the changes to support ES6 in MediaWiki: Timo Tijhof (Krinkle) and DannyS712 for code reviewing the ResourceLoader and minifier changes, Lucas Werkmeister for finding a critical bug in the minifier change, and James Forrester and Ed Sanders for code reviewing the linter changes and releasing new versions of all these packages. * Updates: ** MediaWiki now has built-in support for writing modern JavaScript (ES6)! *** You can now use ES6 code in MediaWiki core, extensions, and skins, as long as it's in a feature that doesn't need to support IE11. ResourceLoader modules that use ES6 code have to be flagged as such, and you will need to put ES6 code in a separate directory so that different eslint rules can be applied. For detailed instructions on how to start using ES6 in your code, see https://www.mediawiki.org/wiki/ResourceLoader/ES6 . *** See wikitech-l for the full announacement == Technology == === Analytics === * Blocked by: * Blocking: ** SRE Service Ops on T274262 * Thank yous: * Updates: === Fundraising Tech === * Blocked by: * Blocking: * Thank yous: * Updates: ** More work on email prefs page https://phabricator.wikimedia.org/T268510 ** Enhancements to optional employer autocomplete field (used for matching gifts) ** Lots of minor Civi fixes https://phabricator.wikimedia.org/T275442, https://phabricator.wikimedia.org/T275445, https://phabricator.wikimedia.org/T277338, https://phabricator.wikimedia.org/T277247 ** Investigating software libraries that handle multiple payment providers https://phabricator.wikimedia.org/T277246, https://phabricator.wikimedia.org/T277245 ** Better error handling for CentralNotice invalid banner name: https://phabricator.wikimedia.org/T173782 === Platform === * Blocked by: None * Blocking: * Thank yous: ** From SRE Service Ops for working on T274262 * Updates: === Engineering Productivity === ==== Release Engineering ==== * Blocked by: ** * Blocking: ** * Thank yous: ** Moritz & John for assistance with GitLab / CAS ** Alex ServiceOps: Kudos on codfw k8s upgrade! * Updates: ** Deployments/Covid-19 https://wikitech.wikimedia.org/wiki/Deployments/Covid-19 ** Train Health *** Last week: 1.36.0-wmf.34 [[phab:T274938]]  *** This week: 1.36.0-wmf.35 [[phab:T274939]]  *** Last week: 1.36.0-wmf.36 [[phab:T274940]]  === Site Reliability Engineering === * Blocked by: ** Analytics on T274262 ** Product infrastructure on T274262 * Blocking: * Thank yous: * Updates: * SRE ServiceOps upgrade of the k8s codfw kubernetes cluster completed. Traffic is being repooled, do reach out to us on T277191 if issues are observed. k8s eqiad cluster to probably follow next week. === WMDE Technical Wishes === * Blocked by: * Blocking: * Thank yous: * Updates: * Due to user feedback, we will change the settings of the Popups extension so that reference previews and page previews can be enabled separately. Today’s reference previews release will not happen and is being rescheduled. * Making simplifications to the reportupdater script, to support Hive queries natively, plus minor streamlining of the format and config. https://gerrit.wikimedia.org/r/c/analytics/reportupdater/+/667192 == Cross-cutting == * Blocked by: ** [long term] Search Platform: PHP 8.0 work is long-term blocked on the migration to ElasticSearch 7.0 https://phabricator.wikimedia.org/T263142 * Blocking: ** None? * Thank yous: ** Roan and Kunal for driving the support for ES6 and ES5 rules in our eslint linting (now rolled out). ** Adam Wight for working to modernise Wikidata's data-values/value-view linting tools. * Updates: ** PHP 8.0 work is focussed on helping upstream provide forwards and backwards compatibility in Elastica-related PHP code. ** CI tools' upgrade status is a little behind: https://libraryupgrader2.wmcloud.org/status?branch=master

1 0

codfw kubernetes cluster upgrade this week
by Alexandros Kosiaris 17 Mar '21

17 Mar '21

Hello everyone, TL;DR if you are not deploying services to the codfw kubernetes cluster, you can safely skip this. Long version: After having tested twice our cluster reinitialization procedure, this week we will be reinitializing our codfw kubernetes cluster. All traffic will be drained from it beforehand and we expect no user visible impact. However, for the duration of the process, the kubernetes codfw cluster will be unavailable to deployers and thus efforts to deploy to it will fail or worse, not have the expected outcomes. This is normal until SRE serviceops announces that the cluster is fully operational again. SRE service-ops will be deploying all services before marking the cluster as usable and pooling traffic back to it, so there will be no need for deployers to re-deploy their services. For your convenience the list of services that are currently deployed on that cluster is: apertium api-gateway blubberoid changeprop changeprop-jobqueue citoid cxserver echostore eventgate-analytics eventgate-analytics-external eventgate-logging-external eventgate-main eventstreams eventstreams-internal linkrecommendation mathoid mobileapps proton push-notifications recommendation-api sessionstore similar-users termbox wikifeeds zotero Regards, -- Alexandros Kosiaris Principal Site Reliability Engineer Wikimedia Foundation

2 2

[Train] 1.36.0-wmf.35 status update
by Ahmon Dancy 17 Mar '21

17 Mar '21

The 1.36.0-wmf.35 train was briefly rolled out to group0 but was rolled back due to an increase in logged errors attributed to T277362[0]. All wikis are back to 1.36.0-wmf.34. See the train blockers task[1] for all details about this week's train. Thanks in advance for resolution of this issue! Sincerely, your train operator. [0] https://phabricator.wikimedia.org/T277362 [1] https://phabricator.wikimedia.org/T274939

1 0

The Wikimedia Enterprise API project
by Liam Wyatt 16 Mar '21

16 Mar '21

Dear Wikitech/Wikitech-Ambassadors, Over the last few months, a small team at the Wikimedia Foundation has been working on a project that has been discussed by many people in our movement for many years: building ‘enterprise grade’ services for the high-volume commercial reusers of Wikimedia content. I am pleased to say that in a remarkably short amount of time (considering the complexity of the issues: technical, strategic, legal, and financial) we now have something worthy of showing to the community, and we are asking for your feedback. Allow me to introduce you to the Wikimedia Enterprise API project – formerly codenamed “okapi”. While the general idea for Wikimedia Enterprise predates the current movement strategy process, its recommendations [0] identify an enterprise API as one possible solution to both “Increase the sustainability of our movement” and “Improve User Experience.” That is, to simultaneously create a new revenue stream to protect Wikimedia’s sustainability, and improve the quality and quantity of Wikimedia content available to our many readers who do not visit our websites directly (including more consistent attribution). Moreover, it does so in a way that is true to our movement’s culture: with open source software, financial transparency, non-exclusive contracts or content, no restrictions on existing services, and free access for Wikimedia volunteers who need it. The team believes we are on target to achieve those goals and so we have written a lot of documentation you get your feedback about our progress and where it could be further improved before the actual product is ‘launched’ in the next few months. We have been helped in this process over the last several months by the approximately 100 individual volunteers (from many corners of the wikiverse) and representatives of affiliate organisations who have reviewed our plans and provided invaluable direction. Pointing out weaknesses and opportunities, or areas lacking clarity and documentation in our drafts. A essay describing the “why?” and the “how?” of this project is now on Meta: https://meta.wikimedia.org/wiki/Wikimedia_Enterprise/Essay Also now published on Meta are an extensive FAQ [1] and operating principles [2]. Much of this documentation is already available in French, German, Italian, and Spanish. For technical specifics, the new documentation on MediaWiki.org describes the product strategy and roadmap, work currently underway, design documents, as well as infrastructure decisions and future plans: https://www.mediawiki.org/wiki/Wikimedia_Enterprise The team is particularly interested in your feedback on how we have designed the checks and balances to this project - to ensure it is as successful as possible at achieving those two goals described above while staying true to the movement’s values and culture. For example: Is everything covered appropriately in the “Principles” list? Is the technical documentation on MediaWiki.org clear? Are the explanations in the “FAQ” about free-access for community, or project’s legal structure, or the financial transparency (etc.) sufficiently detailed? Meet the team and Ask Us Anything: The central place to provide written feedback about the project in general is on the talkpage of the documentation on Meta at: https://meta.wikimedia.org/wiki/Talk:Wikimedia_Enterprise Equally, for technical comments or questions the talkpage on MediaWiki.org: https://www.mediawiki.org/wiki/Talk:Wikimedia_Enterprise <https://meta.wikimedia.org/wiki/Talk:Wikimedia_Enterprise> On this Friday (March 19) we will be hosting two “Office hours” conversations where anyone can come and give feedback or ask questions: - 13:00 UTC via Zoom at https://wikimedia.zoom.us/j/95580273732 - 22:00 UTC via Zoom at https://wikimedia.zoom.us/j/92565175760 (note: this is Saturday in Asia/Oceania) Other “office hours” meetings can be arranged on-request on a technical platform of your choosing; and we will organise more calls in the future. We will also be attending the next SWAN meetings (on March 21) https://meta.wikimedia.org/wiki/Strategic_Wikimedia_Affiliates_Network, and also the next of the Wikimedia Clinics https://meta.wikimedia.org/wiki/Wikimedia_Clinics Moreover, we would be very happy to accept any invitation to attend an existing group call that would like to discuss this topic (e.g. an affiliate’s members’ meeting). On behalf of the Wikimedia Enterprise team, *Liam Wyatt [Wittylama]* WikiCite <https://meta.wikimedia.org/wiki/WikiCite> Program Manager & Wikimedia Enterprise <https://meta.wikimedia.org/wiki/Okapi> Community Liaison Wikimedia Foundation [0] https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recomme… [1] https://meta.wikimedia.org/wiki/Wikimedia_Enterprise/FAQ [2] https://meta.wikimedia.org/wiki/Wikimedia_Enterprise/Principles

1 0

Help on Improving Software Documentation Through Code Reviews
by Felipe Ebert 16 Mar '21

16 Mar '21

Dear members of Wikimedia, We are an international team of researchers, from the University of Bari - Italy, Federal University of Pernambuco - Brazil, University of Adelaide - Australia, and Eindhoven University of Technology - the Netherlands. The goal of our research is to improve software documentation and maintainability of open-source projects by providing automatic support of source code comments based on code review discussions. We would like to learn identifying relevant information from code review discussions such that tooling can be developed to improve software documentation and maintainability of open-source projects. Therefore, we would like to talk to open-source developers and interview them. If you are interested in talking about your experiences as an open-source reviewer then please schedule a meeting with us using YouCanBook.me here: [ https://tue-interview.youcanbook.me]. We are interested in different experiences, therefore, we are looking to talk to people of all age-groups, genders, and people with different roles in open-source projects. So even whether you are a first-time contributor or a senior maintainer don’t hesitate to contact us. The interview itself will take no longer than 30 min and will be scheduled using Microsoft Teams. We will record the interview and the recording and transcript of the interview will be stored securely, and only made available to the researchers that are involved in this project. Additionally, we plan to use anonymized results of the interview in a scientific publication. Kind regards and thanks in advance, -- Nicole Novielli, University of Bari, Fernando Castor, Federal University of Pernambuco, Christoph Treude, University of Adelaide, Alexander Serebrenik, Eindhoven University of Technology, Felipe Ebert, Eindhoven University of Technology

1 0

Need guidance to start
by Rahul Gandhi 15 Mar '21

15 Mar '21

Hello, I m Rahul seeking forward to contribute and make an impact by working with you on projects . hoping to hear from you soon regards Rahul Gandhi

2 1

Re: [Wikitech-l] about jawp mailing list
by darkofwiki＠yahoo.co.jp 13 Mar '21

13 Mar '21

I'm not sure because I didn't understand English exactly, but if I need to log in to register, I can't do it now because I'm globally locked. I also contacted Steward, but I haven't heard back yet. In any case, thank you for your guidance. Rightandlight

2 1

GSOC
by Muhammad Imran 13 Mar '21

13 Mar '21

hey, my name is imran. i want to start contribution on your new announced projects for GSOC.. how can i start need guidance. thanks imran

2 1

[BREAKING CHANGE] Require MySQL 5.6 for pt-heartbeat lag detection in MW 1.36
by Timo Tijhof 13 Mar '21

13 Mar '21

TLDR: * We'd like to drop MySQL 5.5 support for the "lagDetectionMethod=pt-heartbeart" option in $wgLBFactoryConf. * If you have not configured the lagDetectionMethod option, or use MySQL 5.6+, then this does not affect you. Hi, If you host MediaWiki using MySQL (or MariaDB) and have a cluster of two or more database hosts (using replication), then MediaWiki uses lag detection, via the wikimedia/rdbms library. For example, if lag is too high, MediaWiki tries to connect to a different replica database, or it may automatically set the wiki in read-only mode for a few seconds until replication catches up. By default, MediaWiki uses the MySQL built-in "Seconds_Behind_Master" feature to power this lag detection. We also support use of Percona's pt-heartbeat service, which can be more accurate, [1] and is what WMF currently uses. However, we are currently unable to use its accuracy very well, because TIMESTAMPDIFF is not supported in MySQL 5.5 (it was introduced in MySQL 5.6.4). [2] In order to make pt-heartbeat more useful as a lag detection method, whilst avoiding expensive roundtrips or runtime detection (which are not acceptable in this hot code path), we'd either have to support three lag detection methods, or to change the current one to require MySQL 5.6. MySQL 5.5 reached end-of-life in Dec 2018, and there is an open proposal at T273375 to drop support for it completely in a future version of MediaWiki. [3] However, I'd like to propose we drop support for it now with the pt-heartbeat feature specifically, as being opt-in and rarely used, so as to not require additional complexity and maintenance for us in the form a third lag detection method. Especially, as it might not be used by anyone. If you're affected by this, then the upcoming MediaWiki 1.36 release would require that you either set MW to use the default lag detection instead, or upgrade to MySQL 5.6+. Task: https://phabricator.wikimedia.org/T248481 Patch: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/657471 -- Timo Tijhof Performance Team Wikimedia Foundation [1] https://www.percona.com/blog/2014/05/02/how-to-identify-and-cure-mysql-repl… [2] https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-4.html [3] https://phabricator.wikimedia.org/T273375

1 0

(no subject)
by Yash Dubey 11 Mar '21

11 Mar '21

Hi all, I am Yasharth Dubey currently in 2nd-year undergrad studying CSE at IIIT Dharwad, India. I have a good experience in web development. and would like to contribute and look forward to participating for GSOC 2021 opting for this org. I am very much interested in Upgrade WebdriverIO to the latest version for all repositories this project and I am looking forward to working with you for a long time.

3 2

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 2021