Wikitech-l

wikitech-l@lists.wikimedia.org

26 participants
23119 discussions

Talk to the Search Platform / Query Service Team—March 6, 2024
by Guillaume Lederrey 06 Mar '24

06 Mar '24

Hello all! The Search Platform Team usually holds an open meeting on the first Wednesday of each month. Come talk to us about anything related to Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query Service (WCQS), etc.! Feel free to add your items to the Etherpad Agenda for the next meeting. Details for our next meeting: Date: Wednesday, March 6, 2024 Time: 16:00-17:00 UTC / 08:00 PST / 11:00 EST / 17:00 CET Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours Google Meet link: https://meet.google.com/vgj-bbeb-uyi Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927 Have fun and see you soon! Guillaume -- *Guillaume Lederrey* (he/him) Engineering Manager Wikimedia Foundation <https://wikimediafoundation.org/>

1 1

1.42.0-wmf.21 train is blocked
by Jaime Nuche 06 Mar '24

06 Mar '24

Hi there, The 1.42.0-wmf.21 version of MediaWiki is currently blocked at group0 due to: - https://phabricator.wikimedia.org/T359290: ArgumentCountError: Too few arguments to function MediaWiki\Extension\Gadgets\GadgetRepo::titleWithoutPrefix(), 1 passed in [...]/extensions/Gadgets/includes/GadgetResourceLoaderModule.php Thank you for your help resolving this issue! -- Your humble train toiler -- Jaime Nuche Software Engineer III Wikimedia Foundation <https://wikimediafoundation.org/>

1 0

Wikimedia Gerrit is not responding
by Punith Nayak 06 Mar '24

06 Mar '24

Hello, ```~/portals$ git pull origin master ssh: connect to host gerrit.wikimedia.org port 29418: Network is unreachable fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.``` I am facing this issue .Can anyone suggest me the cure for this

2 1

Redesigning the Community Wishlist Survey
by Sandister Tei 05 Mar '24

05 Mar '24

Hello everyone, how are you? I'm writing because of your interest in Wikimedia technical development. Community Tech, the team that organizes the Community Wishlist Survey <https://meta.wikimedia.org/wiki/Community_Wishlist_Survey>, has been tasked to design a new Wishlist that is continuous, better integrated into annual planning, and can efficiently run the intake of community-submitted technical problems. Our goal is to pilot this new Wishlist in July 2024. We invite you to have a chat with Jack Wheeler <https://en.wikipedia.org/wiki/User:JWheeler-WMF>, who has recently joined the Wikimedia Foundation as the Lead Community Tech Manager and is responsible for the Future of the Wishlist <https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/Future_Of_The_Wis…> . Jack would like to have a conversation with you, to get input for the design of the new survey, starting with how to define a "Wish." Community Tech would appreciate you chatting with him; your input will be invaluable. You can check out Jack's first message to the community <https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/Future_Of_The_Wis…>, where you can find a link to proceed to book time to talk to him, or share your ideas directly on the talkpage with him. Best regards, Sandister Tei <https://meta.wikimedia.org/wiki/User:STei_(WMF)> (she/her) Community Relations Specialist (Community Tech & Trust and Safety) Wikimedia Foundation

1 0

remote access for vps
by Tim Moody 05 Mar '24

05 Mar '24

I am trying to reach a remote mysql database from a vps using python. The destination server has created an opening in the firewall for the request, but I am still getting network unreachable errors. I gave the ip of the proxy for the vps, obtained with ping, as the expected ip. I now tried accessing a web site I control from the same vps also in python using requests.get, and in the web server log I see the request coming from what looks to be a gateway (xxx.xxx.xxx.1, rather than the proxy xxx.xxx.xxx.nnn) Is this to be expected and can I rely on the address for such requests? Thanks, Tim

2 6

MediaWiki Insights: February edition
by Birgit Müller 01 Mar '24

01 Mar '24

Hi All, welcome to the monthly MediaWiki Insights email! Like last time <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/January_2…>, we’re starting this email by celebrating volunteer contributors who got their first patch merged in MW core, WMF deployed extensions or services over the past month: A big thanks to GergesShamon and Agent Isai for their contributions! Welcome :-) Many thanks also to the reviewers - volunteers and staff - of patches by new contributors. Your support is invaluable for helping people contribute to MediaWiki effectively and make it a fun first experience! The focus of this edition of the monthly MW Insights email lies on our multi-year initiatives: Migration of MediaWiki from bare metal to Kubernetes <https://wikitech.wikimedia.org/wiki/MediaWiki_On_Kubernetes> in Wikimedia Production, Parser Unification <https://www.mediawiki.org/wiki/Parsoid/Parser_Unification> and RESTBase deprecation <https://phabricator.wikimedia.org/project/profile/6289/>. These initiatives involve many people and projects, require orchestrated efforts and coordination, and will help us in many different ways. Another thing that these initiatives have in common is that we’re getting closer to being able to benefit from these efforts :-). Project Snapshots: Milestones reached on 3 multi-year projects MediaWiki on Kubernetes migration is 75% complete, completing migration of all internal traffic, all scheduled jobs and reaches 50% global traffic milestone! Often shortened as mw-on-k8s, MediaWiki on Kubernetes is a multi-year effort to move all of the MediaWiki deployments running on WMF production infrastructure to the new WikiKube platform. The migration is underway and very recently a new milestone was hit where the WikiKube platform now serves 50% of end user requests <https://phabricator.wikimedia.org/T290536>. At half mark, having more percentage of traffic on WikiKube, Service Operations is working with Release Engineering to make changes to monitoring tools to surface any issues during deployments to continue with further ramps. Also, almost the entirety of what is called internal traffic <https://phabricator.wikimedia.org/T333120>, that is traffic that is generated by applications running in the infrastructure and reaching out to MediaWiki for various purposes is migrated to WikiKube. A special mention should go to MediaWiki Jobs fully migrated just a week ago <https://phabricator.wikimedia.org/T349796>. Feel free to follow the higher umbrella task <https://phabricator.wikimedia.org/T290536> and/or MediaWiki_On_Kubernetes on Wikitech <https://wikitech.wikimedia.org/wiki/MediaWiki_On_Kubernetes>. This migration will unleash the ability to deploy multiple versions of code simultaneously. Also, this will help enhance platform capabilities to build dockerized isolated environments for coding, testing and even production debugging. MediaWiki on Kubernetes will allow us to deprecate and eventually remove a lot of our in-house developed code. Another benefit is that we will be able to react to sudden traffic spikes, like newsworthy events better, as the flexing up and down is a matter of configuration change. This enables efficient placement of workloads, packing workloads in a more environmentally friendly way, increasing hardware utilization. It takes a village to get this far: A big thanks to the Service Operations team (Clément Goubert, Giuseppe Lavagetto, Alexandros Kosiaris, Kamila Součková, Hugh Nowlan, Effie Mouzeli, Reuven Lazarus, Jannis Mayboom and Kavitha Appakayala) for their leadership on this project, the Release Engineering team (specifically: Dan Duvall, Jeena Huneidi, Tyler Cipriani and Ahmon Dancy) for their work on Blubber <https://wikitech.wikimedia.org/wiki/Blubber>, the Deployment Pipeline <https://wikitech.wikimedia.org/wiki/Deployment_pipeline> and Scap <https://wikitech.wikimedia.org/wiki/Scap>, Dom Walden from Quality and Test Engineering for crafting and executing a plan to test the first deployment of MediaWiki on Kubernetes, and everyone else who has contributed in the one way or the other! <3 More milestones: We’re seeing the first lights at the end of the tunnel of another multi-year initiative: The *parser unification* <https://www.mediawiki.org/wiki/Parsoid/Parser_Unification>. One week ago, Parsoid Read Views was rolled out to first wikis: Parsoid is now the default read views renderer on the Foundations’ Office Wiki and Wikitech DiscussionTools. This early experimentation allows us to find issues in a limited space, which will help us evaluate readiness of the feature and increase our confidence for future rollouts <http://mediawiki.org/wiki/Parsoid/Parser_Unification/Confidence_Framework>. A huge thanks to Subbu Sastry, Mateus Santos, CScott, Isabelle Hubert-Pallatin, Arlo Breault, Shannon Bailey, Yiannis Giannelos and Sérgio Lopes for making this work! Many thanks also to Daniel Kinzler: His work on the RESTBase deprecation directly helped us get to this milestone :-) *RESTBase deprecation*: We have been continuously working on decoupling services from RESTBase, aiming for the modernisation and sustainability of Wikimedia products in our services platform. The MediaWiki Interfaces team finished up reimplementation of Reading Lists endpoints in MW REST API <https://phabricator.wikimedia.org/T348491> and are now confirming with affected callers <https://phabricator.wikimedia.org/T357478> that the new endpoints meet their needs before rerouting calls <https://phabricator.wikimedia.org/T348493> and retiring old code <https://phabricator.wikimedia.org/T348494>. The overall effort <https://phabricator.wikimedia.org/T336693> will not only move us forward on RESTBase retirement, but also reduce the total amount of code we have to maintain. Many thanks to Bill Pirkle, Atieno Njira, Wendy Quarshie, and Daniel Kinzler for making this work! We also fully turned off Parsoid cache storage in RESTBase - clients will get outputs direct from MediaWiki and the cache will be handled by ParserCache. Next, we will re-route clients directly to MediaWiki and fully remove Parsoid from RESTBase (T344944 <https://phabricator.wikimedia.org/T344944>). The Page Content Service (PCS) will also handle its own cache <https://phabricator.wikimedia.org/T348995> and we are ready to test the new capabilities in staging soon. Many thanks to Yiannis Giannelos and the Content Transform team and to Daniel Kinzler for his efforts and support on decoupling Parsoid from RESTBase! All of these multi-year initiatives help us increase sustainability and maintainability of the platform, streamline engineering and developer workflows, and unlock the path for new and improved platform capabilities and product opportunities. Outlook: Knowledge Platform in the annual plan 2024/2025 The Wikimedia Foundation has recently published the draft objectives by the Product & Technology department <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…> for the next annual plan on Meta, alongside an introduction by Selena Deckelmann and a few questions that we’re exploring <https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_Annual_Plan/2024-…>. Your input on these questions is very welcome! The draft objectives include “Knowledge Platform I” - centered around MediaWiki platform evolution and “Knowledge Platform II” - centered around developer/engineering services and workflows. The objectives show only the high-level direction for next year. The draft “key results” (currently work in progress) will give a better idea of what areas of work we’re thinking about. We’ll be publishing these in March and share the link + invitation for feedback with this list again. Thanks all for reading, Birgit -- Birgit Müller (she/her) Director of Product, MediaWiki and Developer Experiences Wikimedia Foundation <https://wikimediafoundation.org/>

2 1

Phabricator monthly statistics - 2024-02
by aklapper＠wikimedia.org 01 Mar '24

01 Mar '24

Hi Community Metrics team, This is your automatic monthly Phabricator statistics mail. Accounts created in (2024-02): 312 Active Maniphest users (any activity) in (2024-02): 1111 Task authors in (2024-02): 611 Users who have closed tasks in (2024-02): 323 Projects which had at least one task moved from one column to another on their workboard in (2024-02): 329 Tasks created in (2024-02): 2470 Tasks closed in (2024-02): 2419 Open and stalled tasks in total: 53762 * Only open tasks in total: 52769 * Only stalled tasks in total: 993 Median age in days of open tasks by priority: Unbreak now: 99 Needs Triage: 962 High: 1310 Normal: 2013 Low: 2582 Lowest: 3012 (How long tasks have been open, not how long they have had that priority) To see the names of the most active task authors: * Go to https://wikimedia.biterg.io/ * Choose "Phabricator > Overview" from the top bar * Adjust the time frame in the upper right corner to your needs * See the author names in the "Submitters" panel TODO: Numbers which refer to closed tasks might not be correct, as described in https://phabricator.wikimedia.org/T1003 . Yours sincerely, Fab Rick Aytor (via community_metrics.sh on phab1004 at Fri 01 Mar 2024 12:00:19 AM UTC)

1 0

[Google Season of Docs] Call for documentation projects and technical writers
by Alexandra Paskulin 29 Feb '24

29 Feb '24

Hi all, We’re excited to announce Wikimedia’s participation in Google Season of Docs! 🎉 For the first time since 2020, Wikimedia is applying for Google Season of Docs[1]: a program that provides grants to technical writers to work on documentation for open-source projects. This year, we’ll be selecting one Wikimedia documentation project and, if accepted by Google, hiring one technical writer to complete the project. For details about the program and how to apply, see the wiki page[2]. Here's how you can get involved: - [Until March 22] Propose a project, share feedback on a project, or volunteer to help support a project[3]. - [Until April 28] Apply as a technical writer. We highly encourage Wikimedians to apply! Even if you’re not a professional technical writer, we value experience working on wikis. Our goal is to use this program to improve MediaWiki.org and other Wikimedia technical documentation, supplementing the work done by volunteers and staff. We’re hoping to use this year’s edition as a model to expand the program to multiple projects in future years. Let's make this a successful season of documentation together! 📚 Best, - Alex and Onyinyechi [1] - https://developers.google.com/season-of-docs [2] - https://www.mediawiki.org/wiki/Season_of_Docs/2024 [3] - https://www.mediawiki.org/wiki/Season_of_Docs/2024#Volunteering_to_support_… -- Alex Paskulin Technical Writer Wikimedia Foundation

1 0

[Train] 1.42.0-wmf.19 / wmf.20 status: blocked on T336504 (Transcluding Special:Prefixindex forces default skin), may require Monday rollback
by Brennen Bearnes 26 Feb '24

26 Feb '24

This week's 1.42.0-wmf.20 version of MediaWiki is blocked[0], and 1.42.0-wmf.19 may require a Monday rollback, which is a situation we hope to avoid. We can't proceed until the following issue is resolved: * T336504 - Transcluding Special:Prefixindex can force the default skin - https://phabricator.wikimedia.org/T336504 For context, see the Village pump discussion linked here: * https://phabricator.wikimedia.org/T336504#9572477 Once this issue is resolved, the train can proceed normally for the week. Thank you for any help! -- Your designated sacrificial train victims [0]. https://phabricator.wikimedia.org/T354438

1 0

Northward Datacentre Switchover (March 2024)
by effie mouzeli 26 Feb '24

26 Feb '24

Dear all, *"There is nothing permanent except change - Heraclitus"* On *Wednesday March 20th 2024,* the SRE team will run a planned datacentre switchover, moving all wikis from *codfw* to *eqiad*. This is an important periodic test of our tools and procedures, to ensure the wikis will continue to be available even in the event of major technical issues in our primary home. It also gives all our SRE and ops teams a chance to do maintenance and upgrades on systems in codfw that normally run 24 hours a day. The switchover process requires a brief read-only period for all Foundation-hosted wikis, which will start on *Wednesday March 20th 2024 @ 14:00 UTC*, and will last for just a few minutes while we execute the migration as efficiently as possible. All our public and private wikis will be continuously available for reading, as usual, but editing will be unavailable during the process. Users will see a notification of the upcoming maintenance, and anyone still editing will be asked to try again in a few minutes. CommRel will soon begin notifying communities of the read-only window. If you like, you can follow along on the day in the public *#wikimedia-operations* channel on IRC. To report any issues, you can reach us in *#wikimedia-sre* on IRC, or file a Phabricator ticket <https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?projects=Data…>with the #datacenter-switchover tag; we'll be monitoring closely for reports of trouble during and after the switchover. The switchover and its preparation will be tracked under https://phabricator.wikimedia.org/T357547. On behalf of the SRE team, please excuse the disruption, and we would like to thank everyone in various departments who are involved in planning this work. If you have any questions, please reply directly to this email. Kind Regards, -effie

2 1

Jump to page:

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