Hello,
This email contains updates for September 30, 2020. For the HTML version,
see: https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-09-30
Cheers,
Deb
------------------------
*= 2020-09-30 =*
== Product ==
=== iOS native app ===
* Updates:
** Released minor bug fix version [[phab:project/view/4831/|6.7.1]]
*** Widgets bugs/polish and Chinese variant fix
** In development on [[phab:project/view/4992/|6.7.2]]
*** Article as a Living Document experiment
=== Structured Data ===
* Updates: "beta" milestone for mediasearch
** A/B testing of the mediasearch algorithm in Special:Search on commons
showed a strong preference for the new search, so we're all v pleased about
that \o/
=== Abstract Wikipedia ===
* Updates:
** Voting in the
[[metawiki:Abstract_Wikipedia/Wiki_of_functions_naming_contest|community
naming contest]] for what to call the central wiki of functions is underway.
** Initial Vue rich editing interface has landed, with huge thanks to
Arthur P. Smith.
** Currently working on using ZType data to enforce structure when editing
ZObjects.
** Next up, converting the Vue editing interface into a hybrid view/edit
mode.
== Technology ==
=== Site Reliability Engineering ===
* Updates:
** Almost all services now behind TLS and the services proxy for talking to
each other. A minor outage for citoid, but otherwise going pretty well.
--
deb tankersley (she/her)
sr program manager, engineering
Wikimedia Foundation
I am happy to announce the belated availability of the general release of
MediaWiki 1.35!
Tarballs have already been uploaded, and the git tag has been pushed.
Thanks to everyone who helped out with this release, especially thanks to
those who tested out the release candidates and provided feedback, as well
as the developers who worked hard to get several important fixes merged in
time for the 1.35 final release. To see what's changed in 1.35, see the
release notes below.
Please note that the PHP version requirement has been raised from 7.2.9 in
MediaWiki 1.34 (and 7.0 in MediaWiki 1.31), to 7.3.19.
MediaWiki 1.35 is an LTS and is due to be supported until the end of
September 2023.
As a reminder, 1.31 is due to become end of life in June 2021. 1.34 is due
to become end of life in November 2020.
As per the pre-release announcement, 1.35.0 also includes some security
fixes that weren't in the release candidates, which came out yesterday for
the ther supported MediaWiki branches.
Known/outstanding issues:
* VisualEditor and Parsoid are now bundled in the tarball and no longer
need a separate Node.js service. The documentation for this still may still
require some updates. Please report any bugs [2] if this affects you.
* (T259685) Zeroconf (zero-configuration) VisualEditor/Parsoid doesn't work
using SQLite as the database backend for MediaWiki. This is due to the lack
of write concurrency in SQLite. If you wish to use this feature, it is
recommended to use MySQL/MariaDB rather than SQLite.
* Watchlist expiry (behind the $wgWatchlistExpiry flag) is currently still
experimental. It should become stable in a later point release. Please
report any issues/bugs [3].
== Security fixes ==
* (T232568, CVE-2020-25813) SECURITY: SpecialUserrights: If a viewer lacks
`hideuser`, ignore hidden users.
* (T255918, CVE-2020-25812) SECURITY: Unescaped message used in HTML on
Special:Contributions.
* (T256171, CVE-2020-25815) SECURITY: Unescaped message used in HTML within
LogEventsList.
* (T258763, CVE-2020-17367, CVE-2020-17368) SECURITY: Prevent invoking
firejail's --output functionality.
* (T86738, CVE-2020-25814) SECURITY: mediawiki.jqueryMsg: Sanitize URLs and
'style' attribute.
* (T115888, CVE-2020-25828) SECURITY: mediawiki.js: Escape HTML in
mw.message( ... ).parse().
* (T260485, CVE-2020-25869) SECURITY: ActorMigration: Load user from the
correct database.
* (T260485, CVE-2020-25869) SECURITY: ensure actor ID from correct wiki is
used.
* (T251661, CVE-2020-25827) SECURITY: TOTP throttle not enforced cross-wiki.
== Links to all mentioned tasks ==
* https://phabricator.wikimedia.org/T232568
* https://phabricator.wikimedia.org/T255918
* https://phabricator.wikimedia.org/T256171
* https://phabricator.wikimedia.org/T258763
* https://phabricator.wikimedia.org/T86738
* https://phabricator.wikimedia.org/T115888
* https://phabricator.wikimedia.org/T260485
* https://phabricator.wikimedia.org/T251661
=== Changes since MediaWiki 1.35.0-rc.3 ===
* (T261258) Remove checks for ancient ImageMagick versions in BitmapHandler.
* (T260232) Don't include null page ids in query list for category dumps.
* (T260009) Check existing watchitem when saving action=watch.
* (T259055) Correct success messages for action=watch.
* mediawiki.page.ready: Simpler tablesorter/makeCollapsible call.
* mediawiki.page.ready: Fix skin override config flags, wrong way round.
* (T262175, T248512) Remove requirement for ApiWatchlistTrait to be in
ApiBase.
* (T259053, T260434) Watchlist: Fix updateWatchLink removing css class when
action=watch.
* (T261901, T261476) mediawiki.notification: Don't close notif when
clicking <select> element.
* (T251506) Sanitizer: Truncate IDs to a reasonable length.
* (T259452) Parsoid updated to v0.12.0.
* (T261970) watch.ajax: Add expiry support to watchpage.mw event.
* (T262900) Fix failure of rebuildLocalisationCache.php due to
ResourceLoader hook.
* (T263014) Hard deprecate File::userCan() with $user=null.
* (T262547) Use localized success message after watching via action=watch.
* (T201491) Fix typo 'Watchlst' in `apihelp-edit-param-watchlistexpiry`.
* (T261081) Installer: consistently reset Language objects.
* (T250449, T250450) Installer: consistently reset Language objects.
* Explicitly wrap some XML calls in libxml_disable_entity_loader().
* (T262934) Ensure dropdown label is always on its own line.
* (T246855) resourceloader: Use a local HookRunner.
* (T263604) Have findBadBlobs.php require Maintenance.php rather than
cleanupTable.inc.
* (T263606) Set fake time, to avoid flaky tests.
* (T261325) Add FindMissingActors script.
* (T262364) shell: Don't blacklist /run/firejail.
* (T263655) NewPagesPager: Ignore nonexistent namespaces.
* Update specialPageAliases and magicWords for Egyptian Arabic (arz).
* (T261347) ParserOutput: don't throw on bad editsection.
* (T255918, CVE-2020-25812) SECURITY: Unescaped message used in HTML on
Special:Contributions.
* (T256171, CVE-2020-25815) SECURITY: Unescaped message used in HTML within
LogEventsList.
* (T258763, CVE-2020-17367, CVE-2020-17368) SECURITY: Prevent invoking
firejail's --output functionality.
* (T86738, CVE-2020-25814) SECURITY: mediawiki.jqueryMsg: Sanitize URLs and
'style' attribute.
* (T115888, CVE-2020-25828) SECURITY: mediawiki.js: Escape HTML in
mw.message( ... ).parse().
* (T260485, CVE-2020-25869) SECURITY: ActorMigration: Load user from the
correct database.
* (T260485, CVE-2020-25869) SECURITY: ensure actor ID from correct wiki is
used.
* Add Finnish special page aliases.
* Fix GuzzleHttpRequest request headers.
* Fix description for pruneFileCache.php.
* emptyUserGroup.php: handle more than 5000 users.
* Make ApiSandbox copyable URL absolute.
* (T261087) Add a link from a deleted page to that page's logs.
Open Bugs:
[1] https://phabricator.wikimedia.org/project/board/4035/
Bug report form:
[2]
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.35-…
[3]
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.35-…
**********************************************************************
Download:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.tar.gz
Download without bundled extensions:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.0.tar.gz
Patch to previous version (1.35.0-rc.3):
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.patch.gz
GPG signatures:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.0.tar.gz.…https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.tar.gz.sighttps://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.patch.gz.sig
Public keys:
https://www.mediawiki.org/keys/keys.html
Release Notes
https://www.mediawiki.org/wiki/Release_notes/1.35
This is the weekly TechCom board review in preparation of our meeting. If
there are additional topics for TechCom to review, please let us know by
replying to this email. However, please keep discussion about individual
RFCs to the Phabricator tickets.
Activity since Monday 2020-09-21 on the following boards:
https://phabricator.wikimedia.org/tag/techcom/https://phabricator.wikimedia.org/tag/techcom-rfc/
Committee inbox:
- T263904 <https://phabricator.wikimedia.org/T263904>: Are traits part
of the stable interface?
- New question by @DannyS712.
Committee board activity:
- T227776 <https://phabricator.wikimedia.org/T227776>: General
ParserCache service class for large "current" page-derived data
- @daniel's team will soon start work on this project.
- T244058 <https://phabricator.wikimedia.org/T244058>: Strategy for
storing old revisions in ParserCache.
- @daniel analyzed various code paths relating to this.
New RFCs:
- T263841 <https://phabricator.wikimedia.org/T263841>: RFC: Expand API
title generator to support other generated data
- @matthiasmullie started an RFC with interest from Structured Data
and Search Platform teams.
Phase progression:
- T240775 <https://phabricator.wikimedia.org/T240775>: RFC: Support PHP
7.4 preload
- Moves to P3.
- Interest from the Performance Team.
- T260714: <https://phabricator.wikimedia.org/T260714> RFC: Parsoid
Extension API
- Moves to Last Call to be *Approved* on 7 Oct.
- T487 <https://phabricator.wikimedia.org/T487>: RFC: Associated
namespaces
- Moves to Last Call to be *Declined* on 7 Oct.
- @tgr mentions that Bask Wikipedia (eu.wikipedia.org) has a "
Txikipedia <https://eu.wikipedia.org/wiki/Txikipedia:Azala>"
namespace that could benefit from this.
IRC meeting request: (none)
Other RFC activity:
- T260330: <https://phabricator.wikimedia.org/T260330> RFC: PHP
microservice for containerized shell execution
- @tstarling wrote an example to demonstrate how the Score extension
could work.
- T250406 <https://phabricator.wikimedia.org/T250406>: RFC: Hybrid
extension management
- @RHeigl asks about next steps.
- T120085 <https://phabricator.wikimedia.org/T120085>: RFC: Serve Main
Page of Wikimedia wikis from a consistent URL
- @bblack indicates their team considers this an Epic Idea™. Thank
you Brandon.
-- Timo
Hi all,
> *Summary *Push Notifications are now available to enable on all wikis for
> Android & iOS Wikipedia apps
*Background:*
- Wikimedia Product teams needed a new way to drive user engagement and
retention for features like "Thank You's" and "Edit Reminders"
- Similar to web and email notifications, editors receive quick
notifications outside of using the native apps
- Push notifications are a way to send messages to user devices without
the user engaging with the application
- The Product Infrastructure team[1] designed and built the underlying
infrastructure[2] to provide the push notification capability for other
product teams to leverage
- This first release of v1.0.0 provides the following features:
- App users can now receive notifications sooner, even when the app
is not currently running
- App users can subscribe and unsubscribe to receive Echo
notifications
- Echo can send messages to the user via native Wikipedia apps for
Android and iOS
- The system can limit the rate and volume of messages to prevent
server overload
- Invalid subscriptions are automatically removed from the system
upon notification request failure
- You can find more information on our MediaWiki[2] and WikiTech
pages[3]
[1]
https://www.mediawiki.org/wiki/Wikimedia_Product/Wikimedia_Product_Infrastr…
[2]
https://www.mediawiki.org/wiki/Wikimedia_Product_Infrastructure_team/Push_N…
[3] https://wikitech.wikimedia.org/wiki/Push_notifications
Best,
--
Seve Kim *(he/him)*
Sr. Technical Product Manager
<https://wikimediafoundation.org/>
*"Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment."*
Hello Everyone,
TL;DR:
New mailing list for local dev discussion ->
https://lists.wikimedia.org/mailman/listinfo/local-dev
New wiki page for updates ->
https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Local_Dev…
This year’s developer satisfaction survey[0] revealed that many people felt
there wasn’t enough communication around local dev improvement efforts. In
fact, some people didn’t even know that there were any. The following is a
brief history of those efforts and an update on what we have in progress,
as well as some ways for us to communicate and keep informed about the
local development space.
A little under 2 years ago, I took on the task of developing a
container-based development environment for mediawiki and services,
partially since our production deployments are moving in that direction. As
someone who had never done development on Mediawiki and its surrounding
extensions and services, and whose job was not to do that development, this
was (and is) a challenge. Here’s a quick outline of what I, with other
contributors, did since then:
1. Coded and analyzed the 2019 developer satisfaction survey[1] and did
one on one interviews with developers to understand the problems faced by
developers.
- This research provided insights into areas in and out of the scope
of local development that probably deserve more attention
2. Created a prototype in minikube[2]
- Brennen Bearnes created the dev-images repo to support this work
- Demonstrated at the Prague Hackathon in 2019
- Did not generate much interest
- Confirmed suspicions that kubernetes is not an ideal tool for
developing
3. Led local-dev work group meetings
4. Presented findings and ideas at Tech Conf in 2019[3] with Brennen
- Together with session attendees, decided to create
mediawiki-docker[4], a lightweight dev solution for pure mediawiki
developers.
- Had another session to attempt to figure out what kinds of services,
etc, could be grouped together for more complex development environments,
but didn’t explain this in a way that session attendees understood, and
they probably left frustrated
5. Continued work on mediawiki-docker, and a cli[5] to simplify
repetitive docker commands
- Kosta Harlan, along with Brennen, Mukunda Modell, and James
Forrester headed this up
- Zeljko Fillipin (and a bunch of other people!) worked on
documentation of setting up a number of extensions to use with
mediawiki-docker, which indicates some adoption of mediawiki-docker
You can collaborate with us or track our progress by visiting our
phabricator work board[6]. Tasks welcome :)
As a preview, some open tasks are:
- Command-line wrapper for interacting with core's docker-compose stack -
https://phabricator.wikimedia.org/T246111
- Tasks under this task to make the CLI more useful
- Set up distribution of MediaWiki-Docker CLI -
https://phabricator.wikimedia.org/T250241
- Accomplishing this means devs can use cli commands to interact with
mediawiki-docker without cloning the cli repo and building the project
- Set up CI for mediawiki-docker -
https://phabricator.wikimedia.org/T248779
- So we can avoid regressions
We’re still exploring the best way to manage docker-compose files for
different extensions and services for a more complex development
environment.
To address the concerns about lack of communication in a more consistent
manner, I’d like to introduce a long-overdue way for us to have discussion
on local dev topics through a new local-dev mailing list:
https://lists.wikimedia.org/mailman/listinfo/local-dev. I’ve also created
this wiki page for updates about local-dev:
https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Local_Dev….
Since I’ve recently created this page, there is not much to see there at
the moment.
If you've made it this far, thanks for reading! I hope these changes will
help improve communication and collaboration with everyone who wants to
participate.
[0] https://www.mediawiki.org/wiki/Developer_Satisfaction_Survey/2020
[1] https://www.mediawiki.org/wiki/Developer_Satisfaction_Survey/2019
[2] https://gerrit.wikimedia.org/g/releng/local-charts
[3]
https://docs.google.com/presentation/d/1ZuQGkzXylvJnPSmP4epKjsS7TghXvK99AwX…,
https://docs.google.com/presentation/d/15a5yxOyPGlOADIQ6D4MmxM7ucvkec2ySpeR…
[4] https://www.mediawiki.org/wiki/MediaWiki-Docker
[5] https://gerrit.wikimedia.org/g/mediawiki/tools/cli
[6] https://phabricator.wikimedia.org/tag/mediawiki-docker/
--
Jeena Huneidi
Software Engineer, Release Engineering
Wikimedia Foundation
Hi everyone,
I'm a volunteer for QTE and was assigned the task of using
eslint-config-wikimedia 0.16.x in all repositories with Selenium tests
<https://phabricator.wikimedia.org/T254495#6497062> and updating
.eslintrc.json files with the Selenium WDIO test suite. When updating the
wikibase/termbox repo's eslint-config-wikimedia to its current 0.17.0
release and updating eslint to 7.10.0, I receive nearly 900 errors when
running "npm run test:lint"
Most errors are node/no-object-assign, node/no-missing-import,
es/no-object-values.
I understand that the node/no-missing-import errors are mostly coming from
an issue with the module alias "@" defined in package.json but I'm not
certain how to resolve this or proceed on the other errors. Does anyone
have any advice?
Thanks!
Jared
Hello,
This email contains updates for September 23, 2020. For the HTML version,
see: https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-09-23
Cheers,
Deb
------------------------
*= 2020-09-23 =*
== Product ==
=== iOS native app ===
* Updates:
** Monitoring version [[phab:project/view/4661/|6.7.0]] in App Store
*** Widgets v1
** In code freeze on bug fix release [[phab:project/view/4831/|6.7.1]]
*** Widgets bugs/polish and Chinese variant fix
** In development on [[phab:project/view/4992/|6.7.2]]
*** Article as a Living Document experiment
=== Abstract Wikipedia ===
* Updates:
** [[metawiki:Abstract_Wikipedia/Wiki_of_functions_naming_contest|Community
naming contest]] launched for what to call the central wiki of functions.
** Initial bootstrap ZType schemata content now [[phab:T260315|injected
into the wiki on installation]].
** Very basic first pass of the rich editing interface (in Vue) nearing
completion.
** Some consideration of the needs for common widget library in Vue with
WMDE colleagues.
== Technology ==
=== Engineering Productivity ===
==== Quality and Test Engineering ====
* Blocked by:
** Wikidata: [https://github.com/wmde/wdio-wikibase/pull/25 Make
wdio-wikibase work with wdio 6]
=== Site Reliability Engineering ===
* Updates:
** Working on etcd SLOs, api-gateway SLOs with PET, finalizing the TLS
migration for all services.
--
deb tankersley (she/her)
sr program manager, engineering
Wikimedia Foundation
The minutes from TechCom's triage meeting on 2020-09-23.
Present: Tim S, Dan A, Daniel K, Niklas L, Timo T.
RFC: Parsoid Extension API
*
https://phabricator.wikimedia.org/T260714
*
TS: on the basis of Subbu’s comment listing the different
consultations, should go to last call.
*
TT: fine to put on last call
*
DK: no objections, doing
*
On Last Call to be approved on Oct 7.
RFC: Associated namespaces
*
https://phabricator.wikimedia.org/T487
*
DK: use cases mentioned easier to implement with MCR, suggest to
close this RFC.
*
TT: some other theoretical use cases have also been covered by
https://phabricator.wikimedia.org/T165149
*
TT: decline with last call?
*
DK: wouldn’t be opposed to it if someone needed it or would do the
work, but does have merit, just no buy-in.
*
TT: currently, if something doesn’t get resourced, it just stays
in P1.
*
On Last Call to be declined on Oct 7.
Next week IRC office hours
No IRC discussion scheduled for next week.
You can also find our meeting minutes on MediaWiki.org
<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
<https://www.mediawiki.org/wiki/Newsletter:TechCom_Radar> on the wiki.