Wikitech-l July 2020

wikitech-l@lists.wikimedia.org

56 participants
66 discussions

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 08 Jul '20

08 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

TechCom Radar 2020-07-01
by Alexandra Paskulin 07 Jul '20

07 Jul '20

Hi all, This week, we're sending out a more detailed version of the TechCom meeting minutes. Let us know if you find this helpful. Present: Dan Andreescu, Daniel Kinzler, Timo Tijhof, Alex Paskulin, Niklas Laxstrom == RFC Frontend build step == <https://phabricator.wikimedia.org/T199004> == * Recently moved from open to stalled * Discussion of the issues presented in the RFC from a process perspective: * DA: The question on the RFC was originally: How can we implement a build step? The discussion on the RFC has been centered around whether we should implement a build step. The authors are trying to address concerns to enable them to implement it since it’s an industry-wide practice. * TT: We should focus on the underlying problems this is trying to solve. A build step is inevitable. Many problems discussed so far on the RFC don’t call for a build step. There are some architecture issues in the things proposed that can’t be reconciled. We can build towards a deliverable of compiling a Vue component. * DK: Process-wise, what is the problem with a team deciding that they want a server side build step? What’s the impact? In theory, we want to maximize coherence and autonomy; there’s a polarity between the two. * DA: If they find a mainstream way, they’ll migrate to it. I don’t think it’s problematic. They’re saying that they’ll address all the concerns if they can. * TT: This impacts security for the developers running insecure code on developer host machines, security for production (can be contained/network isolated), and security for the end-user (this isn’t just helping create commits or run tests, it modifies and adds code we sent to a billion people’s devices). Reproducing the same locally, in CI and prod. Workflow problems like cherry-pick and revert in production branches. * DK: To what extent are we willing to run arbitrary code on our systems? Which communities do we trust? (Example: Debian maintainers are vetted, NPM packages are not) * TT: NPM packages are known for depending on a lot of unreviewed/unknown code. See <https://phabricator.wikimedia.org/T199004#6045136>. But, there are communities within the NPM ecosystem that follow different principles, and use fewer dependencies. * DA: We could set a policy about reviewing and vendoring such service, run in a sandbox, pinned to specific versions. We could set a requirement that packages need to be vetted. == Send regular overview about Wikimedia development policies == <https://phabricator.wikimedia.org/T164538> * Moved from Inbox to In progress on TechCom board == RFC: Amendment to the Stability interface policy == <https://phabricator.wikimedia.org/T255803> * On last call ending July 8 * Discussion ongoing == RFC: Hybrid extension management == <https://phabricator.wikimedia.org/T250406> * In Phase 3: Explore * Discussion ongoing == Next week public IRC discussion == No discussion scheduled for next week See also the TechCom RFC board <https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>. -- Alex Paskulin Technical Writer Wikimedia Foundation

3 3

Moving from Gerrit to GitLab
by AntiCompositeNumber 06 Jul '20

06 Jul '20

The Wikimedia Engineering Productivity team has decided that Wikimedia projects will move from Gerrit to GitLab for code review and continuous integration. They have decided that this decision is not subject to any formal RFC. Previous attempts to change the code review system went through an RfC. They are, however, looking for feedback. More information is at <https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/GitLab> and the associated talk page. Regards, AntICompositeNumber

4 3

New DB_REPLICA constant; DB_SLAVE deprecated
by Aaron Schulz 04 Jul '20

04 Jul '20

As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA instead of DB_SLAVE, with the old constant left as an alias. This is part of a string of commits that cleaned up the mixed use of "replica" and "slave" by sticking to the former. Extensions have not been mass converted. Please use the new constant in any new code. The word "replica" is a bit more indicative of a broader range of DB setups*, is used by a range of large companies**, and is more neutral in connotations. Drupal and Django made similar updates (even replacing the word "master"): * https://www.drupal.org/node/2275877 * https://github.com/django/django/pull/2692/files & https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a023… I don't plan on doing anything to DB_MASTER, since it seems fine by itself, like "master copy", "master tape" or "master key". This is analogous to a master RDBMs database. Even multi-master RDBMs systems tend to have a stronger consistency than classic RDBMs slave servers, and present themselves as one logical "master" or "authoritative" copy. Even in it's personified form, a "master" database can readily be thought of as analogous to "controller", "governer", "ruler", lead "officer", or such.** * clusters using two-phase commit, galera using certification-based replication, multi-master circular replication, ect... ** https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_… *** http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium… -- -Aaron

4 3

Announcing a new sister project! Welcome, Abstract Wikipedia
by Erica Litrenta 02 Jul '20

02 Jul '20

Hello. (Apologies for cross-posting, and that you are likely not reading this message in your native language: translations of the full announcement may be available on Meta [1], and will be posted to all the wikis in the next few days. Please consider helping with translations in the meantime. Thanks!) The Wikimedia Foundation Board of Trustees has approved a new sister project, temporarily titled "Abstract Wikipedia" [2]. Its goal is to generate baseline encyclopedic content in a multilingual fashion, allowing more contributors and more readers to share more knowledge in more languages. You can learn more on Meta [1] and can also join the new dedicated mailing list [3]. Talk to you soon! [1] https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia/June_… [2] https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia [3] https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia -- Erica Litrenta Manager, Community Relations Specialists https://meta.wikimedia.org/wiki/User:Elitre_(WMF)

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