Wikitech-l March 2021

wikitech-l@lists.wikimedia.org

58 participants
58 discussions

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 12 Mar '21

12 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

[Train] 1.36.0-wmf.34 status update (blocked at group0)
by Brennen Bearnes 10 Mar '21

10 Mar '21

Hi all, The 1.36.0-wmf.29[0] train is currently blocked at group0 by the following issue: * Bug in client error logging stops any errors from being logged in group 0 wikis - https://phabricator.wikimedia.org/T277094 Note that we have recently updated the train policy[1] to use client-side errors as a signal of deployment health. Jon Robson is working on T277094, and hopes to have a fix yet this afternoon, but if this is an area you're familiar with, help is likely welcome. If all issues are resolved before the cutoff at 15:00 PST, the train will roll forward today. Otherwise it will resume tomorrow during the US workday. As ever, you can follow train progress on Freenode's #wikimedia-operations as well as on the blocker task[0]. Regards, -- Your over-communicative train operator [0]. <https://phabricator.wikimedia.org/T274938> [1]. <https://wikitech.wikimedia.org/wiki/Deployments/Holding_the_train#Issues_th…>

1 0

Scrum of scrums/2021-03-10
by Deb Tankersley 10 Mar '21

10 Mar '21

Hello, This email contains updates for March 10, 2021 <https://www.mediawiki.org/wiki/Scrum_of_scrums/2021-03-10>. Cheers, Deb 2021-03-10Callouts - SRE ServiceOps Scheduling upgrade of the main codfw kubernetes cluster. It will be unavailable for a few hours, announcement will be sent when the exact maint window is decided - SRE ServiceOps blocked on - PET on T274262 - Product Infrastructure on T274262 - Analytics on T274262 - Thanks to Language and WMDE for acting on the above task. No updates CommTech, Anti-Harassment, Editing, iOS, Android, Language, Inuka, Library *No notes provided* Parsing, Cloud, FR-Tech, Performance, QTE, Search, Security ProductAnti-Harassment Tools - Thank yous: - Thanks to Lukasz Sobanski and Amir Sarabadani for writing documentation on adding DB tables - Thanks to Timo Tijhof for helping improve the AHT dashboard on logstash Growth - Updates: - Continuing work on Add Link https://wikitech.wikimedia.org/wiki/Add_Link - Continuing to work on exposing more configuration settings to wiki admins T274520 <https://phabricator.wikimedia.org/T274520> T274031 <https://phabricator.wikimedia.org/T274031> - Enabling Growth tools on thwiki T274646 <https://phabricator.wikimedia.org/T274646> Web - Thank yous: - Brandon Black for helping with temporarily disabling the edge caches for a small number of wikis to aid with the Desktop Improvements rollout - Noam Rosenthal for helping with various Page Previews performance improvements and regressions - Adam Wight for working on centralizing the user edit count bucketing logic: https://phabricator.wikimedia.org/T210106 - Updates: - Enabled WVUI search treatment A/B test on more wikis: https://phabricator.wikimedia.org/T249297 - Focused on the language switcher treatment A/B test: https://phabricator.wikimedia.org/T268504 and its subtasks Product Infrastructure - Blocking: - SRE ServiceOps on T274262 Structured Data - Updates: - Focused on blockers for making MediaSearch the default search UI on Commons - Planning and discussion around image recommendations tool Abstract Wikipedia - Blocked by: - None. - Blocking: - None known. - Thank yous: - Search Platform for on-going discussion around discovery needs and how to meet them. - Updates: - Continuing on phase gamma: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Phases - The Wikifunctions logo concept vote closes on Monday 2021-03-15: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Wikifunctions_logo_conce… Language - Thank yous: From SRE Service Ops for T274262 Vue.js - Thank yous: - Timo for code review and getting ES6 support in wikimedia/minifier over the finish line - Updates: - ES6-only module support in ResourceLoader now available ("es6": true); documentation to come - Actual support for serving ES6 code is not yet available but very close, hoping to land it this week. We'll make an announcement and update documentaton once this is merged TechnologyAnalytics - Blocking: - SRE ServiceOps on T274262 Platform - Blocking: - SRE ServiceOps on T274262 Engineering ProductivityRelease Engineering - Updates: - Train Health - Last week: 1.36.0-wmf.33 phab:T274937 <https://phabricator.wikimedia.org/T274937> - This week: 1.36.0-wmf.34 phab:T274938 <https://phabricator.wikimedia.org/T274938> - Last week: 1.36.0-wmf.35 phab:T274939 <https://phabricator.wikimedia.org/T274939> Site Reliability Engineering - Blocked by: - PET on T274262 - Product Infrastructure on T274262 - Analytics on T274262 - Blocking: - None - Thank yous: - Updates: - Scheduling upgrade of the main codfw kubernetes cluster. It will be unavailable for a few hours, announcement will be sent when the exact maint window is decided - SRE Traffic wiping edge caches on a handful of wikis to aid desktop refresh testing - https://phabricator.wikimedia.org/T274784 WMDE Technical Wishes - Thank yous: - Analytics - Updates: - Syntax highlighting “accessible” color schema is ready to test on the beta cluster - Tweaking the shared code for edit count bucketing, https://phabricator.wikimedia.org/T210106 - Still piling up reviews for Analytics. - Would like to deploy a few non-voting jobs for Quibble+Apache 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 - Updates: - Working on splitting our front-end JS linting rules into ES5 and ES6 variants. This will lead to a new release of eslint-config-wikimedia. - There are a few repos still using jsonlint, notably Wikidata's data-values/value-view: https://phabricator.wikimedia.org/T220036 https://libraryupgrader2.wmcloud.org/library/npm/grunt-jsonlint?branch=mast… - PHP 8.0 work is focussed on helping upstream provide forwards and backwards compatibility in Elastica-related PHP code. - CI tools' upgrade status is adequate: https://libraryupgrader2.wmcloud.org/status?branch=master -- deb tankersley (she/her) senior program manager, engineering Wikimedia Foundation

1 0

about jawp mailing list
by darkofwiki＠yahoo.co.jp 10 Mar '21

10 Mar '21

Good evening. I am Rightandlight and I am working on the mailing list for global unlocking and unblocking application including conversation page lock on jawp. Now, on the jawp mailing list, the characters are garbled and I can barely see it in the email, but I can't see it in the archive and it's not seen by many people. Is it possible to eliminate the garbled characters in the jawp mailing list archive? https://lists.wikimedia.org/pipermail/wikija-l/ Rightandlight * I am always looking for someone to unlock or help me with global unlocking. https://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:%E3%82%A2%E3%83%A…

2 1

IE 11 and feature compatibility
by Keegan Peterzell 09 Mar '21

09 Mar '21

Greetings, Starting this month (March 2021) and moving forward, new software features developed by the Wikimedia Foundation for MediaWiki will no longer support Internet Explorer 11 (IE11). Existing software features may be deprecated from IE11 as the browser reaches EOL support from Microsoft. More information about the reasoning behind this is available on mediawiki.org [1]. 1. https://www.mediawiki.org/wiki/Compatibility/IE11 Sincerely, -- Keegan Peterzell (he/him) Technical Collaboration Specialist Wikimedia Foundation

1 0

Increase MediaWiki basic support requirements to TLS 1.2 supporting browsers
by Volker E. 08 Mar '21

08 Mar '21

Hi all, Since January 2020, Wikimedia has not served traffic to browsers which do not support TLS 1.2 [0]. We would like to bump basic MediaWiki software stack support to exclude those very old browsers as well. Our MediaWiki core, extensions and skins basic browser support matrix still includes some end-of-life browsers published between 2007 and 2013 that are only supporting the now insecure ciphers of TLS 1.0 and 1.1. We've gathered stats [1] emphasizing the relatively small access expectations. Now we want to push software stack support to align to those browser versions already in place as minimum in Wikimedia hosted MediaWikis. We're continuing to provide support for browsers published from 2013 on! Note that Internet Explorer 9 and 10 are unaffected by this proposed change as well for the moment. See the specific list on task. [1] What's to win: A great number of design and layout features (CSS, SVG and WAI-ARIA, see the list [2]) which we currently just exceptionally use in some products or via extra effort, performance impacting hacks and workarounds, and maintenance on the developer side. Current support is slowing down some advances in Desktop Improvements and other front-end work. What's to lose: Possible layout issues in third party MediaWikis still targeting those end-of-life browers. Content access should be untouched there. If there are no objections within the next 10 days, we're going to amend the support matrix with aforementioned TLS 1.2 supporting browsers as the minimum. Please let us know about any objections or further inputs, preferably on task. Thanks and best regards, Volker [0] - https://phabricator.wikimedia.org/T238038 [1] - https://phabricator.wikimedia.org/T238038 [1] - https://phabricator.wikimedia.org/T266866 [2] - https://phabricator.wikimedia.org/T266866#6591703 --- Volker E. Lead UX Engineer Desktop Improvements/Design System Wikimedia Foundation

1 0

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