The 1.36.0-wmf.2 version of MediaWiki is currently blocked at group1.[0]
The new version can proceed no further until this issue is resolved:
* Argument 1 passed to Wikimedia\Parsoid\Utils\DOMDataUtils::getDataMw()
must be an instance of DOMElement
- https://phabricator.wikimedia.org/T259311
Thanks for any help resolving this issue. Since we're past today's
cutoff and there are no deploys on Friday, the train can roll forward on
Monday morning, assuming a fix.
Thanks to Mholloway, Msantos, Legoktm, tgr, and RoanKattouw for their
assistance with earlier blockers this week.
-- Your temporary train trundler
[0]. <https://phabricator.wikimedia.org/T257970>
[1]. <https://tools.wmflabs.org/versions/>
Hi all,
Here are the minutes from this week's TechCom meeting:
== RFC: Stop supporting legacy PHP entry point extensions ==
<https://phabricator.wikimedia.org/T258845>
* New RFC by Kunal (Legoktm) that proposes gradually ending support for
legacy
PHP entry points
* TS: The RFC proposes ending support for legacy entry points by MediaWiki
1.43,
which could be five years from now.
* GL: That long of a timeline might be too conservative considering that
there’s a viable
migration path. Wikidata is removing it from production this week. The
percentage of
extensions on gerrit using the new system leads me to believe that we can
do this on
a shorter timeline, especially if there are advantages to not having to
support the legacy
entry points.
* RK: 1.35 will be an LTS release that ships with support for legacy PHP
entry points,
giving longer support to projects that need it. We could remove them before
1.39, our
next LTS release.
* TS: If there’s a large extension or project that needs it, we can be
sensitive to the
timing of the deprecation.
* Discussion continues on the task
== Consolidate language metadata into a 'language-data' library and use in
MediaWiki ==
<https://phabricator.wikimedia.org/T190129>
* NL: No remaining unanswered questions that would change the direction of
the proposal.
* Ready to move from P3 (Explore) to P4 (Tune)
== RFC: Render data visualizations on the server ==
<https://phabricator.wikimedia.org/T249419>
* DA: This RFC is stalled due to pushback on the technical side coupled
with inactivity on
the product side. Client-side visualization seems to be uncontroversial so
far, but I took the
inactivity as a decrease in priority. I’m still interested in the problem
technically, but it needs
proper resourcing and stewardship. Any change away from current
architecture runs into
other problems. I proposed to take a deeper look at how we store graph
definitions.
* GL: We un-deployed Graphoid from Group 0 and 1 only, which may be the
cause of the
lack of feedback.
* DA: I wouldn’t suggest re-deploying Graphoid. The idea was to deploy a
new version,
new repository.
* TT: Removing Graphoid from group 2 could change the priority. When we
un-deploy
Graphoid, there will be a gap when getting things from Siri as well as
impact to the graphs
on pages related to COVID-19. I did hear some interest, but we need actual
resourcing.
* GL: For anything going into production from now on, we’re considering the
typical
performance expected and determining an error budget. If a project overruns
its error budget
for the quarter, the responsible team will be required to do something
about it, either make it
more stable or lose SRE support.
== RFC: Normalize MediaWiki link tables ==
<https://phabricator.wikimedia.org/T222224>
* TT: There’s currently a straw-man proposal open for feedback. Waiting for
DBA feedback.
* No IRC discussion scheduled for 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>
--
Alex Paskulin
Technical Writer
Wikimedia Foundation
Hi all! Question about WikidataPageBanner (https://www.mediawiki.org/wiki/Extension:WikidataPageBanner)... WikidataPageBanner menus are built dynamically and link to section headings on the wiki page where the banner template is used. Is there a way to add WikidataPageBanner menu items that behave like wikilinks and navigate off the page when clicked?
Thank you... Michael H.
Hi,
for HTML version see https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-07-29
Željko
--
= 2020-07-29 =
== 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]]
== SoS Meeting Bookkeeping ==
* Updates:
** Looking for a meeting facilitator for 2020-08-05, 2020-08-12 and
maybe 2020-08-19. The facilitator job is creating a wiki page and
sending mail to wikitech-l.
== Product ==
=== Web ===
* Updates:
** '''Summary''': the Desktop Improvements Project's (DIP) new Vector
is now an opt-in user preference everywhere; continuing WVUI Vector
integration, network client, and search suggestion component.
** [[Reading/Web/Desktop_Improvements|Desktop Improvements Project
(Vector / DIP)]]:
*** [[phab:T250968|<nowiki>[ShoutWikiAds] Replace use of deprecated
hook VectorBeforeFooter</nowiki>]]
*** [[phab:T258588|<nowiki>Sidebar collapsed by default on desktop
improvements</nowiki>]]
*** [[phab:T258058|<nowiki>Enable sidebar instrumentation on test
wikis</nowiki>]]
*** [[phab:T254227|<nowiki>Switch test wikis to new version of vector
by default</nowiki>]]
*** [[phab:T253842|<nowiki>Fix the printable versions of modern
Vector</nowiki>]]
*** [[phab:T249363|<nowiki>Move the existing search to the header in
preparation for Vue.js search development</nowiki>]]
*** [[phab:T257647|<nowiki>Integrate WVUI into Vector for Vue.js
search</nowiki>]]
*** [[phab:T256092|<nowiki>[Modern Vector] Fix broken rendering of
`main` and element in IE9-11</nowiki>]]
*** [[phab:T251212|<nowiki>[Dev] Drop VectorTemplate usage in Vector</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:T237036|<nowiki>ext.uls.interface should set targets and
explicitly not target the Minerva skin</nowiki>]]
*** [[phab:T235712|<nowiki>Fix the most common "Module not loadable on
target mobile" warnings (Oct 2019)</nowiki>]]
*** [[phab:T258728|<nowiki>MobileFrontend browser test failing:
User:<username> "before all" hook – Can't call setValue on element
with selector "#wpName1" because element wasn't found</nowiki>]]
*** [[phab:T258096|<nowiki>Browser test failure: Nested references do
not always open</nowiki>]]
*** [[phab:T240622|<nowiki>[Technical debt payoff] Remove
InlineDiffFormatter and InlineDifferenceEngine from
MobileFrontend</nowiki>]]
*** [[phab:T212465|<nowiki>[EPIC] None of our View's should exhibit 2
levels of inheritance</nowiki>]]
** Standardization
*** [[phab:T250762|<nowiki>UsersMultiselectWidget not announcing
status message</nowiki>]]
*** [[phab:T248062|<nowiki>Deprecate and remove
`.background-image-svg()` mixin from
'mediawiki.mixins.less'</nowiki>]]
*** [[phab:T248047|<nowiki>Deprecate & remove
`.background-image-svg-quick()` mixin from
'mediawiki.mixins.less'</nowiki>]]
*** [[phab:T258752|<nowiki>Unify `line-height` to `20px` in widgets to
simplify code and better i18n</nowiki>]]
** Portals
*** [[phab:T128546|<nowiki>[Recurring Task] Update Wikipedia and
sister projects portals statistics</nowiki>]]
** Miscellaneous
*** [[phab:T147221|<nowiki>Vertical alignment of logos and text in
Notifications popup</nowiki>]]
== Technology ==
=== Engineering Productivity ===
==== Release Engineering ====
* Updates:
** [All] Deployments/Covid-19 [[wikitech:Deployments/Covid-19]]
** Train Health
*** Last week: 1.36.0-wmf.1 - [[phab:T257969]]
*** This week: 1.36.0-wmf.2 - [[phab:T257970]]
*** Next week: 1.36.0-wmf.3 - [[phab:T257970]]
The Search Platform Team
<https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> usually holds
office hours the first Wednesday of each month. Come talk to us about
anything related to Wikimedia search!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, August 5th, 2020
Time: 15:00-16:00 GMT / 08:00-09:00 PDT / 11:00-12:00 EDT / 17:00-18:00 CEST
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vyc-jvgq-dww
Join by phone in the US: +1 786-701-6904 PIN: 262 122 849#
Hope to talk to you in a week!
—Trey
Trey Jones
Sr. Computational Linguist, Search Platform
Wikimedia Foundation
UTC-4 / EDT
Hi all,
https://phabricator.wikimedia.org/T257879 recommends dropping support for
PHP 7.2 in the upcoming MediaWiki 1.35 release. (It would still be
supported in master as it will probably take months for Wikimedia
production to switch.) Tl;dr: 1.35 is an LTS release which we'll support
for 3 years, and supporting an old PHP version in an LTS release tends to
be inconvenient in a number of ways. More details in the task.
Your feedback in the task would be appreciated, especially if you would be
affected by the change in a positive or negative way.
Greetings! I've written a brief blog that describes how Wikimedia uses
optional build steps as an enhancement to ResourceLoader and our
evolving pipeline. If you use ResourceLoader in your projects, you may
find it helpful:
https://phabricator.wikimedia.org/phame/post/view/206/all_code_is_built/
Thank you to the following reviewers for their great feedback: Jan
Drewniak, Santhosh Thottingal, Daniel Cipoletti, Joe Walsh, Bernd
Sitzmann, and Mónica Pinedo Bajo.
Stephen