Wikitech-l January 2022

wikitech-l@lists.wikimedia.org

55 participants
50 discussions

🚂🌈Summary of 1.38.0-wmf.19 train deployment
by Brennen Bearnes 31 Jan '22

31 Jan '22

This email is a summary of the Wikimedia production deployment of 1.38.0-wmf.19 * Conductor: Brennen Bearnes * Backup Conductor: Jeena Huneidi * Blocker Task: T293960 <https://phabricator.wikimedia.org/T293960> * Current Status <https://versions.toolforge.org>: Stable on all wikis. 📈 By the Numbers Sparklines comparing with the last 5 trains. * 319 Patches ▆▁▇▇█ * 1 Rollback ▄▁█▁▂ * 1 Day of delay ▂▂█▁▂ * 18 Blockers ▂▁▂▆█ 🌈 Trainbow Love 😻 Thanks to folks who reported or resolved blockers: * Amir Sarabadani * Taavi Väänänen * Zabe * Legoktm * Umherirrender * Bartosz Dziewoński * Jon Robson * Urbanecm * Tyler Cipriani * Ammarpad * Lucas Werkmeister (WMDE) Others no doubt contributed, but there'd be a rather long list of blockers to parse to figure out who I'm missing. Additionally, a special thanks to everyone who helped debug T300214 - 'No such file or directory' CI failures in multiple repos <https://phabricator.wikimedia.org/T300214> in #wikimedia-releng: * Zabe * hashar * bd8080 * James_F * dancy * thcipriani * Amir1 * andrewbogott * TimStarling ...and anyone else I'm more than likely missing in scrollback. -- Brennen Bearnes Release Engineering Wikimedia Foundation

1 0

January 2022 Edition of the Technical Community Newsletter
by Melinda Seckington 31 Jan '22

31 Jan '22

Hi everyone, We’re happy to announce the January 2022 edition of the Technical Community Newsletter < https://www.mediawiki.org/wiki/Technical_Community_Newsletter/2022/January>. The newsletter is compiled by the Wikimedia Developer Advocacy Team. It aims to share highlights, news, and information of interest from and about the Wikimedia technical community. The Wikimedia Technical Community is large and diverse, and we know we can't capture everything perfectly. We would love to hear your ideas for future newsletters. Let us know what you would like to see or highlights you would like us to include. Subscribe to the Technical Community Newsletter <https://www.mediawiki.org/wiki/Newsletter:Technical_Community_Newsletter>, if you'd like to keep up with essential updates and information. Thanks, Melinda -- Melinda Seckington Developer Advocacy Manager Wikimedia Foundation <https://wikimediafoundation.org/>

1 0

Interested in Contributing to Wikimedia Foundation
by Ankit Aggarwal 29 Jan '22

29 Jan '22

Respected Sir/Madam, I'm Ankit Aggarwal, a 3rd year engineering student at MAIT. I am new to open source contribution. I would love to contribute to your organization. I am interested in Web Development. Can you please guide me how i can start contributing. My Technical skills are: 1). HTML 2). CSS 3). JavaScript 4). ReactJS Hoping for a positive response. Regards Ankit Aggarwal

2 1

Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery)
by Kunal Mehta 28 Jan '22

28 Jan '22

Hi, On 1/1/22 12:10, Asaf Bartov wrote: > It seems to me there are *very few* people who could change status quo, > not much more than a handful: the Foundation's executive leadership (in > its annual planning work, coming up this first quarter of 2022), and the > Board of Trustees. If the goal is to get paid WMF staff to fix the issues, then you're correct. However, I do not believe that as a solution is healthy long-term. The WMF isn't perfect and I don't think it's desirable to have a huge WMF that tries to do everything and has a monopoly on technical prioritization. The technical stack must be co-owned by volunteers and paid staff from different orgs at all levels. It's significantly more straightforward now for trusted volunteers to get NDA/deployment access than it used to be, there are dedicated training sessions, etc. Given that the multimedia stack is neglected and the WMF has given no indication it intends to work on/fix the problem, we should be recruiting people outside the WMF's paid staff who are interested in working on this and give them the necessary access/mentorship to get it done. Given the amount of work on e.g. T40010[1] to develop an alternative SVG renderer, I'm sure those people exist. Take moving Thumbor to Buster[2] for example. That requires forward-porting some Debian packages written Python, and then testing in WMCS that there's no horrible regressions in newer imagemagick, librsvg, etc. I'm always happy to mentor people w/r to Debian packaging (and have done so in the past), and there are a decent amount of people in our community who know Python, and likely others from the Commons community who would be willing to help with testing and dealing with whatever fallout. So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly. [1] https://phabricator.wikimedia.org/T40010 [2] https://phabricator.wikimedia.org/T216815 -- Legoktm

11 10

Re: [Wikimedia-l] Uplifting the multimedia stack (was: Community Wishlist Survery)
by Strainu 28 Jan '22

28 Jan '22

> So where is the best current place to discuss scaling Commons, and all that entails? My impression is that we don't have one. All we hear is "it needs to be planned", but there is no transparency on what that planning involves or when it actually happens. > I'd be surprised if the bottleneck were people or budget The main problem I see is that we end up in this kind of situation. Scaling and bug fixing critical features should be part of the annual budget. Each line of code deployed to production wikis should have an owner and associated maintenance budget each year. Without this, the team will not even commit reviews - see the thread on wikitech a few months back where a volunteer programmer willing to work on Upload Wizard was basically told "We will not review your code. Go fork." > Some examples from recent discussions Also improvements to the Upload Wizard. There are quite a few open items in Phab on this. I really hope you will have better luck than others with bringing this issue up in the priority list for next year - multimedia support is growing more outdated by the minute. Strainu Pe joi, 30 decembrie 2021, Samuel Klein <meta.sj(a)gmail.com> a scris: > Separate thread. I'm not sure which list is appropriate. > ... but not all the way to sentience. > > The annual community wishlist survey (implemented by a small team, possibly in isolation?) may not be the mechanism for prioritizing large changes, but the latter also deserves a community-curated priority queue. To complement the staff-maintained priorities in phab ~ > For core challenges (like Commons stability and capacity), I'd be surprised if the bottleneck were people or budget. We do need a shared understanding of what issues are most important and most urgent, and how to solve them. For instance, a way to turn Amir's recent email about the problem (and related phab tickets) into a family of persistent, implementable specs and proposals and their articulated obstacles. > An issue tracker like phab is good for tracking the progress and dependencies of agreed-upon tasks, but weak for discussing what is important, what we know about it, how to address it. And weak for discussing ecosystem-design issues that are important and need persistent updating but don't have a simple checklist of steps. > So where is the best current place to discuss scaling Commons, and all that entails? Some examples from recent discussions (most from the wm-l thread below): > - Uploads: Support for large file uploads / Keeping bulk upload tools online > - Video: Debugging + rolling out the videojs player > - Formats: Adding support for CML and dozens of other common high-demand file formats > - Thumbs: Updating thumbor and librsvg > - Search: WCQS still down, noauth option wanted for tools > - General: Finish implementing redesign of the image table > > SJ > On Wed, Dec 29, 2021 at 6:26 AM Amir Sarabadani <ladsgroup(a)gmail.com> wrote: >> >> I'm not debating your note. It is very valid that we lack proper support for multimedia stack. I myself wrote a detailed rant on how broken it is [1] but three notes: >> - Fixing something like this takes time, you need to assign the budget for it (which means it has to be done during the annual planning) and if gets approved, you need to start it with the fiscal year (meaning July 2022) and then hire (meaning, write JD, do recruitment, interview lots of people, get them hired) which can take from several months to years. Once they are hired, you need to onboard them and let them learn about our technical infrastructure which takes at least two good months. Software engineering is not magic, it takes time, blood and sweat. [2] >> - Making another team focus on multimedia requires changes in planning, budget, OKR, etc. etc. Are we sure moving the focus of teams is a good idea? Most teams are already focusing on vital parts of wikimedia and changing the focus will turn this into a whack-a-mole game where we fix multimedia but now we have critical issues in security or performance. >> - Voting Wishlist survey is a good band-aid in the meantime. To at least address the worst parts for now. >> >> I don't understand your point tbh, either you think it's a good idea to make requests for improvements in multimedia in the wishlist survey or you think it's not. If you think it's not, then it's offtopic to this thread. >> [1] https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… >> [2] There is a classic book in this topic called "The Mythical Man-month" >> >> On Wed, Dec 29, 2021 at 11:41 AM Gnangarra <gnangarra(a)gmail.com> wrote: >>> >>> we have to vote for regular maintenance and support for essential functions like uploading files which is the core mission of Wikimedia Commons

3 2

MediaWiki Language Extension Bundle 2022.01
by Kartik Mistry 27 Jan '22

27 Jan '22

Hello all, I would like to announce the release of MediaWiki Language Extension Bundle 2022.01. This bundle is compatible with '''MediaWiki 1.36''' or above and requires '''PHP 7.3.19''' or above. Next MLEB is expected to be released in 3 months. If there are very important bug fixes, we will do an intermediate release. Please give us your feedback at [[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]]. * Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2022.01.tar… * sha256sum: 0cb434980b399f7bac42a92c9f171b6c9041cb998e3b2b0fcf16daf58c43fe61 * Signature: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2022.01.tar… Quick links: * Installation instructions are at: https://www.mediawiki.org/wiki/MLEB * Announcements of new releases will be posted to a mailing list: https://lists.wikimedia.org/postorius/lists/mediawiki-i18n.lists.wikimedia.… * Report bugs to: https://phabricator.wikimedia.org/project/view/1464/ Release notes for each extension are below. -- Kartik Mistry == Highlights == * '''MLEB now requires MediaWiki 1.36 and PHP 7.3.19''' == Babel, cldr, CleanChanges and LocalisationUpdate == * Localisation and maintenance updates. == Translate == * Fix Special:PageMigration - Page search suggestion does not work ({{phab|T217726}}) * Fix UI issue: the page moves from bottom to top when new messages are loaded in List tab ({{phab|T295655}}, {{gerrit|738587}}) * Migrate tables to an abstract schema ({{phab|T268576}}, {{gerrit|735613}}) * Improve UX on Special:AggregateGroups and add collapsibility ({{phab|T90511}}) * Feature: Special:Translate: Make the target language visible in the translation UI ({{phab|T296987}}, {{gerrit|743383}}) * Feature: Special:Translate: Make the target language selector a bit more prominent ({{phab|T296986}}, {{gerrit|743397}}) * Performance: Special:ActiveLanguages should not perform slow queries if results are cached ({{phab|T285314}}, {{gerrit|747122}}) * Feature: Add a new Javascript hook, <code>mw.translate.translationView.stateChange</code>, fired when the state is updated ({{phab|T297129}}, {{gerrit|745997}}) * Remove unused Configure extension integration ({{gerrit|751382}}) * Feature: Add reason dropdown on PageTranslationDeletePage ({{phab|T153542}}, {{gerrit|754490}}) * Add filters to <code>meta=messagegroupstats</code> API ({{phab|T298736}}, {{gerrit|752000}}) * Allow exporting AggregateMessageGroups in offline format via CLI ({{phab|T299493}}, {{phab|T263268}}, {{gerrit|755356}}) === Breaking changes === * Remove backward compatibility for MW <= 1.35 ({{phab|T298788}}, {{gerrit|752166}}) == UniversalLanguageSelector == * Remove backward compatibility for MW <= 1.35 * Localisation and maintenance updates. === Font updates === * Add Awami Nastaliq font ({{phab|T290510}}, {{gerrit|737206}}) * Update OpenDyslexic ({{gerrit|737207}}) * Update GentiumPlus font ({{phab|T298613}}, {{gerrit|737206}}) -- Kartik Mistry | કાર્તિક મિસ્ત્રી kartikm.wordpress.com

1 0

[Train] 1.38.0-wmf.19 status update (blocked at group0 on T300194)
by Brennen Bearnes 26 Jan '22

26 Jan '22

Hi all, The 1.38.0-wmf.19[0] train is currently blocked at group0 by the following regression: * Wikimedia\Rdbms\DBTransactionSizeError: Transaction spent [n]s in writes, exceeding the 3s limit - https://phabricator.wikimedia.org/T300194 Thanks in advance for any assistance with this! As ever, you can follow train progress on libera.chat's #wikimedia-operations as well as on the blocker task[0]. Regards, -- Your plodding train purveyors [0]. https://phabricator.wikimedia.org/T293960 [1]. <https://wikitech.wikimedia.org/wiki/Deployments/Holding_the_train#Issues_th…>

1 0

Wikimedia Cloud Services can probably host your project!
by Andrew Bogott 26 Jan '22

26 Jan '22

This is just a note to inform and/or remind you that the WMF has its own internal cloud solution, Wikimedia Cloud VPS[0]. If you are considering starting up a project on AWS, Google Cloud, or the like, please consider using our internal, already-paid-for service. We provide: - Easy virtual machine creation and management[1] - Persistent block storage[2] - Self-serve provisioning of Mariadb and PostgreSQL database servers[3] (and self-serve management of Mariadb user access) - Automatic HTTPS/TLS termination for web endpoints[4] - Other things! Start experimenting today with a project request here: https://phabricator.wikimedia.org/project/view/2875/ Q. Isn't WMCS only for community/volunteer projects? A. Nope. Dozens of internal WMF projects are already hosted on Cloud VPS. The advantage of using a community-focused platform is that when the time comes to involve volunteers, contractors, or WMDE staff in your work, you will find the path to access simple and straightforward. Q. Is WMCS a safe place for my data and passwords? A. Yes. If you want to store user PII on a Cloud VPS system then there will need to be some official discussion, but that is true for any PII hosted on any cloud platform. Q. What is this going to cost me or my department? A. WMCS provides free, unmetered resources to all projects related to the WMF's mission and the Wikimedia community. If you have extremely large resource needs (dozens of cores or terabytes of data) then there may be some discussion about long-term cloud capacity but we don't have a billing department and don't plan on ever having one. Q. What kind of software can I host on Cloud VPS? A. Any software with an OSI-approved license can be freely installed. Q. I really need <specific feature that I know is available on AWS>. Do you support that? A. Maybe! Or even if we don't, we might be about to. Feel free to respond to this ticket, or contact a member of the WMCS team via email, slack, or IRC. Q. Why would I use Cloud VPS when I already know how to use AWS? A. There are so many reasons! Some of them are financial, ideological, and legal, but the biggest reason is that we are here to help you. WMCS staff and volunteers provide ongoing support for Cloud VPS via phabricator and IRC, and we care about whether or not your project succeeds. Thank you for reading! [0] https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS [1] https://wikitech.wikimedia.org/wiki/Help:Horizon_FAQ [2] https://wikitech.wikimedia.org/wiki/Cinder [3] https://wikitech.wikimedia.org/wiki/Help:Adding_a_Database_to_a_Cloud_VPS_P… [4] https://wikitech.wikimedia.org/wiki/Help:Using_a_web_proxy_to_reach_Cloud_V…

1 0

UserMerge has been undeployed from Wikimedia wikis
by Taavi Väänänen 25 Jan '22

25 Jan '22

Hi all, I've just undeployed the UserMerge extension from all Wikimedia wikis[0], after it has been unused and unmaintained for multiple years. This means that policy[1] no longer requires that all other WMF deployed extensions are compatible with it. [0]: https://phabricator.wikimedia.org/T216089 [1]: https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment -- Taavi (User:Majavah)

2 1

Summary of 1.38.0-wmf.18 train deployment
by Jeena Huneidi 24 Jan '22

24 Jan '22

🚂🌈Summary of 1.38.0-wmf.18 train deployment This email is a summary of the Wikimedia production deployment of 1.38.0-wmf.18 - Conductor: Jeena Huneidi - Backup Conductor: Mukunda Modell - Blocker Task: T293959 <https://phabricator.wikimedia.org/T293959> - Current Status <https://versions.toolforge.org> 🔢 According to our calculations Sparklines comparing with the last 5 trains. - 287 Patches ▆▇▁██ - 0 Rollbacks ▂▄▁█▁ - 0 Days of delay ▁▂▂█▁ - 13 Blockers ▄▃▁▃█ 😻 Trainbow Love 🎉 Thanks to folks who reported or resolved blockers: - Kosta Harlan - Brennen Bearnes - Tyler Cipriani - Peter Pelberg - Taavi Väänänen - Umherirrender - Zabe - James D. Forrester - Samuel - Bartosz Dziewoński - Jon Robson - Gergő Tisza -- Jeena Huneidi Software Engineer, Release Engineering 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 January 2022