Wikitech-l July 2020

wikitech-l@lists.wikimedia.org

56 participants
70 discussions

TechCom Radar 2020-07-08
by Kate Chapman 12 Jul '20

12 Jul '20

Hi All, Here are the minutes from this week's TechCom meeting: * On last call ending 22nd July RFC: HTML element for inline media from wikitext <https://phabricator.wikimedia.org/T251641> * Approved: RFC: Amendment to the Stability interface policy < https://phabricator.wikimedia.org/T255803> * No IRC meeting next week You can also find our meeting minutes at < https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Minutes> See also the TechCom RFC board < https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>. If you prefer you can subscribe to our newsletter here < https://www.mediawiki.org/wiki/Newsletter:TechCom_Radar> Thanks, Kate -- Kate Chapman (she/her/hers) Director of Architecture, Architecture Team Wikimedia Foundation kchapman(a)wikimedia.org

1 0

Hard deprecation of the Revision class
by Petr Pchelko 12 Jul '20

12 Jul '20

Hey all, TLDR: your extension CI might break due to hard deprecation of Revision class. Today a Gerrit change[1] has been merged, hard deprecating MediaWiki core Revision class. Loads of work has been done to prepare for this moment, mostly by a volunteer developer DannyS712 with code review support from almost every corner of the MediaWiki developer universe. You can judge the amount of work by the number of subtasks in the tracking ticket[2] A lot of effort has been done to update all the WMF deployed extensions and some non-deployed ones to the new code, In accordance with stable interface policy deprecation section[3]. However due to the gravity of a change, we might have missed some corner cases. Missed usages will not cause problems in production since the only consequence of using hard deprecated code is a log message, but some CI tests might start failing. If you find your tests failing, please replace all the usages of the Revision class according to 1.35 release notes, and your tests should start passing again. In case you’re having troubles doing it, please reach out to core platform team and we will try to help. This is a huge milestone in decoupling MediaWiki core! We understand that this might cause some inconveniences, apologize for them and are hoping we can help with resolving any issues. Cheers. Petr Pchelko 1. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/608845 2. https://phabricator.wikimedia.org/T246284 3. https://www.mediawiki.org/wiki/Stable_interface_policy#Deprecation

7 6

Re: [Wikitech-l] [Wikimedia-l] Fwd: Re: CI and Code Review
by Aron Manning 11 Jul '20

11 Jul '20

*Cross-posting to wikitech-l as it's a topic related to development.* On Wed, 8 Jul 2020 at 23:01, Maarten Dammers <maarten(a)mdammers.nl> wrote: > Of interest to the wider community. I really hope this is not part of a > larger pattern of the WMF ignoring community. > > Maarten I've had a great experience in the "Discussion Tools" (WMF's talk pages reply tool) project. Feedback is properly documented, considered and worked on. I recall having quite some input on the UI design and I'm happy that resulted in a clean, focused UI. That is an example to follow, but there's a lot to improve in other areas. Although I favor GitLab, I was surprised that this introduction didn't have a community round other than the developer feedback survey. I assume the non-public results of the surcey justify this move and I'm happy with it, so no complaints, but it came as a surprise to me that this is happening as such discussions were promptly shut down on phabricator: I've given this suggestion once in a related topic and rude comments told me this is off-topic and basically to keep it to myself. The discussion ended abruptly and the ticket was closed within a day. There was another discussion <https://phabricator.wikimedia.org/T167547> closed and declined after 4 comments from 3 participants in 12 minutes. This discussion was later referred to as the official decision to avoid GitLab :-) And prior to the current announcement, an attempt was made to rename this discussion to "RFC: ..." I have a hard time to understand these actions and correlate it to any consensus process and transparent communication. The recent update to the history diff font <https://phabricator.wikimedia.org/T250393> also could have been communicated better. Informing editors about a simple solution (to change your editor font setting or add some CSS to common.css/global.css) would have avoided disruption and community backlash. Instead the latter solution was only shared reactively after complaints and the simple solution was not suggested. I'd hope the developer team gives more attention to communication and transparency. I think this has improved in the last year, primarily in the preparation of Desktop Improvements and Talk pages project, but it's still a long path to improve engagement generally with the community and in particular development matters. Aron (Demian)

1 0

CI comments filtering in Gerrit
by Antoine Musso 09 Jul '20

09 Jul '20

Hello, >From now on, new CI messages send to Gerrit can be filtered out in the web interface by selecting the "Only comments" filter. That is done by sending a review with '--tag autogenerated:ci' which get caught by the filter. That might help reducing the clutter on the change view, and in most case the tests results you are interesting in are the latest which are now displayed as a table just below the commit message (was T256575 done by Paladox and QChris). An example of the feature is at: https://phabricator.wikimedia.org/T48148#6294913 Do note that old CI messages written for the last 9 years or so are not tagged and can not be filtered out. If you see any bot for which messages should be filtered, please report them on https://phabricator.wikimedia.org/T48148 or reach out to the bot author(s) to use a tag! -- Antoine "hashar" Musso

2 1

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

08 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

CI and Code Review
by Greg Grossmeier 08 Jul '20

08 Jul '20

First, apologies for not announcing this last week. A short work week coupled with a new fiscal year delayed this until today. tl;dr: Wikimedia will be moving to a self-hosted (in our datacenter(s)) GitLab Community Edition (CE) installation for both code review and continuous integration (CI). Longer: We are making a change to our code review and continuous integration (CI) systems in response to a complex set of inputs (Developer Satisfaction Survey[0], passing comments/critiques, an evaluation of replacement continuous integration infrastructure[1], feedback from leaders in the Foundation, etc) and evaluation conversations with Wikimedia Technology department leadership (eg CTO, VPs) and representatives from Wikimedia SRE, Architecture, Core Platform, Product, Security, and Technical Engagement teams. In those conversations with Technology department leadership, coordinated by our CTO Grant Ingersoll, we determined that an RFC was not needed for this decision[2]. We plan to replace Gerrit and Zuul+Jenkins (the software that powers our CI system) with GitLab. We hope that making a move to GitLab now will address most of the concerns and desires that are able to be addressed via software alone. We join a growing list of other free/open knowledge organizations using a self-hosted GitLab installation and look forward to the added benefits of working together with them. The project portal page lives at: https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/GitLab It is a living documentation portal and we will continue to update it as we go. The Talk: page is also available for your feedback and questions (and is already being used). We hope everyone will join in to make this transition as successful as possible. Notably, I would like to point people to the conversation[3] about evaluating pull-request style workflows and finding a recommended workflow for our projects. While pull-request workflows are much more common in the wider software development world{{cn}} we would like to provide as much guidance as reasonable so that we are using our tools to the best of their ability. Here is the list of stakeholders as we have them now. In a RACI[4] model these would be Consulted. These are the people the Wikimedia Release Engineering team will be consulting with most closely as they get this going. * SRE/Service Ops - Mark and delegate(s) * Security - Chase P and Scott B * Core Platform Team - TBD * Technical Engagement - TBD * Product - Daniel C “TBD” means we have asked for a representative and we’re waiting to hear back on confirmation. We also have a few other non-WMF groups that we have already reached out to or will be shortly to include in that list; feel free to ping me with other suggestions. What does this mean for you as you do your work today? Right now, nothing. But as we set up the new GitLab installation we will be looking for early adopters to give us feedback as we work on improvements. As we start to migrate more users and repositories we will strive to help everyone as much as possible and reasonable. It should go without saying that this includes completely volunteer projects using the shared infrastructure. The full timeline and plan will be posted to the above project portal page. For the avoidance of doubt, this does not impact issue/task management; that will remain in Phabricator. Thank you, Greg PS: Please let me know where else this announcement should be sent. [0] https://www.mediawiki.org/wiki/Developer_Satisfaction_Survey/2020 [1] https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Future… [2] see also: https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Charter#Areas_… [3] https://www.mediawiki.org/wiki/Topic:Vpbwawb4lkdy89ym [4] https://en.wikipedia.org/wiki/Responsibility_assignment_matrix

4 3

Scrum of scrums/2020-07-08
by Željko Filipin 08 Jul '20

08 Jul '20

Hi, for HTML version see https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-07-08 Željko -- = 2020-07-08 = == Callouts == * Release Engineering ** [All] Review guidance at [[wikitech:Deployments/Covid-19]] and Code Deployment Office Hour at 17:00UTC in #wikimedia-office ** "scap sync" will be renamed to "scap sync-world" in the next release. If you use "scap sync" non-interactively, please add a note to: [[phab:T250302]] (and also, explain why you're using it) ** scap sync now has option --canary-wait-time; [[phab:T217924]] == Product == === iOS native app === * Updates: ** Bug fixes and feature task planning for 6.7 - [[phab:project/view/4661]] ** WWDC research === Android native app === * Updates: ** Continuing work on onboarding design refresh - [[phab:project/view/4819/]] === Web === * Updates: ** '''Summary''': content max-width and sidebar persistence for Desktop Improvements Project (DIP), building button and input for Vue.js search. ** [[Reading/Web/Desktop_Improvements|Desktop Improvements Project (Vector / DIP)]]: *** [[phab:T256992|<nowiki>[site request] enable 100% sampling for sidebar instrumentation on test.wikipedia.org</nowiki>]] *** [[phab:T254195|<nowiki>Implement a core 'clearfix' mixin in mediawiki.mixin and evaluate deprecation/removal of 'visualClear' class</nowiki>]] *** [[phab:T246420|<nowiki>Limit content width, and refine alignment & styling of relevant elements</nowiki>]] *** [[phab:T256092|<nowiki>[Modern Vector] Fix broken rendering of `main` and `dialog` elements in IE9-11</nowiki>]] *** [[phab:T251212|<nowiki>[Dev] Drop VectorTemplate usage in Vector</nowiki>]] *** [[phab:T255319|<nowiki>Eventually deprecate SkinTemplateNavigation::SpecialPage and SkinTemplateNavigation hooks in favor of SkinTemplateNavigation::Universal </nowiki>]] *** [[phab:T244392|Vue.js search case study]]: **** See [[Reading/Web/Desktop Improvements/Vue.js case study/Status log|weekly status updates]]. ** Mobile website (MinervaNeue / MobileFrontend): *** [[phab:T235961|<nowiki>Remove 'mediawiki.ui.anchor' module</nowiki>]] *** [[phab:T235712|<nowiki>Fix the most common "Module not loadable on target mobile" warnings (Oct 2019)</nowiki>]] *** [[phab:T247033|<nowiki>Add 'i18n-directionality.less' file to core and extract overarching theme styles from legacy.less</nowiki>]] ** Standardization *** [[phab:T256713|<nowiki>Amend VisualEditor's WikimediaUI themed ProgressBar to new look</nowiki>]] *** [[phab:T256520|<nowiki>Consider 'normalize' stylesheet RL module</nowiki>]] ** Portals *** [[phab:T128546|<nowiki>[Recurring Task] Update Wikipedia and sister projects portals statistics</nowiki>]] ** Miscellaneous *** [[phab:T237036|<nowiki>ext.uls.interface should set targets and explicitly not target the Minerva skin</nowiki>]] == Technology == === Fundraising Tech === * Updates: ** Figuring out what old data we can delete, and how ** Working out the kinks in the matching gifts sync / donation form employer autocomplete ** More optimizing data sync between CiviCRM and bulk mail house ** CentralNotice workaround for browsers not letting pixels set banner hide cookies: === Engineering Productivity === ==== Release Engineering ==== * Updates: ** [All] Deployments/Covid-19 [[wikitech:Deployments/Covid-19]] ** Train Health *** Last week: 1.35.0-wmf.39 - [[phab:T254176]] *** This week: 1.35.0-wmf.40 - [[phab:T256668]] *** Next week: 1.35.0-wmf.41 - [[phab:T256669]]

1 0

July 2020 Technical Community Newsletter
by Sarah R 08 Jul '20

08 Jul '20

Hi Everyone, We’re happy to announce the July 2020 edition of the Technical Community Newsletter <https://www.mediawiki.org/wiki/Technical_Community_Newsletter/2020/July> is now available. 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. Check it out, and learn about what technical contributors have been up to this past quarter, upcoming conferences & calls for papers, and how to get involved. The Wikimedia Technical Community is large and diverse, and we know we can't capture everything perfectly. We welcome 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. Kindly, Sarah R. Rodlund Technical Writer, Developer Advocacy <https://meta.wikimedia.org/wiki/Developer_Advocacy> srodlund(a)wikimedia.org

1 0

Proposed breaking change to Command::restrict()
by Kunal Mehta 08 Jul '20

08 Jul '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I'm proposing a breaking change to MediaWiki\Shell\Command::restrict(). I made a mistake in my original implementation of this function that I believe we're better off fixing. For background on what shell restrictions are, see <https://www.mediawiki.org/wiki/Manual:Shell_framework#Restrictions>. To summarize the ticket I filed <https://phabricator.wikimedia.org/T257278>: Command manages $restrictions as bitfields and by default sets it to Shell::RESTRICT_DEFAULT (39). To disable restrictions, the idea was to call ->restrict( Shell::RESTRICT_NONE );. However, ->restrict() adds to $restrictions (using |=) instead of overwriting...so it's impossible to disable a default restriction. My proposal is to have ->restrict() overwrite the current $restrictions instead of adding to it. Based on codesearch, every non-test caller is already set up to work this way, so in practice, it shouldn't be a breaking change. The Gerrit patch for this is <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/609870/> and contains multiple examples of the correct way to call the fixed function . Comments, alternative suggestions welcome. I would like to get this in for 1.35 if possible. Thanks, - -- Legoktm -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAl8Fs30ACgkQ8QX4EBsF JptHyA//Uo5h3l4EUTJlBNIoOR1jKlN7onKfzHZrxDPKvLDlBCrAYB9YLkxZ6Pfb /SP8c0mUH5UvQBH+SL/qZPmHTfwbnB1auOuyzu+XedFZxET26kh29glWSwbxf9KL i+7dAuO8gFM/q7gIuYMCc+TmZu+SQEOgr4Ek+iD/fIcQondpxmzaAdTUJ8UPn9a0 OLONdqo7elFM8VRID0YlIzO4DCKymmpW/aEiJChOTxy11IUr4ZQ8n1r8aY66LZ2y qlsm00hofPkVH19Pjqj5T1E80etUcMwh6uVdpctgJBNFXNYIuaAG6sHatbZXH3WJ /zIfzhNBXB19233fQ3Cn/f+fLYXQPGxw5Z/ATEtlHSAFAeWwXtkpvOED0fAO0X8r 0BbAdHkWYPkbGTPimrf5R1dwvmnw09p4qGUMGGb9Nw6KwsJpOMoZL8oBMa120ktI FzJ6EPB3iv1XbsY1IOaekmdThISV/V1pB4PpteqpK44li+1kPCg4sJIqyaFMG86p ejgzlXMiLw8g9skezFGsZJeaUbGwu+Fu0GuAQ/4+py50jsmAEsO49u6md7TtzhUu Loa39JpisHk6Kk5otfL+f1b8MWNBBVuqixQTCL/T78G3jfotG9swjuqqKq8MNY6U qgx2lL8LEEaUik7MwhvxJ00A6p89HV9KTezTdwmlwWwmKA83ec0= =HouQ -----END PGP SIGNATURE-----

2 1

Testing via GitHub actions
by Jeroen De Dauw 07 Jul '20

07 Jul '20

Hey, Has anyone created a GitHub action to run tests for a MediaWiki extension yet? I'd like to run the PHPUnit tests for some of my extensions via GitHub actions. Unfortunately this is not as simple as in the typical PHP project, since doing composer install + vendor/bin/phpunit does not cut it. It'd be fantastic if someone already created a clean action to do this that I can copy. Best -- Jeroen De Dauw | www.EntropyWins.wtf <https://EntropyWins.wtf> Professional wiki hosting and services: www.Professional.Wiki <https://Professional.Wiki> Entrepreneur | Software Architect | Open Source | Longtermism

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