Hi,
for HTML version see
https://www.mediawiki.org/wiki/Scrum_of_scrums/2019-11-27
Željko
--
= 2019-11-27 =
== Callouts ==
* Release Engineering - unusual train schedule:
*** This week: 1.35.0-wmf.8 - group0 only because of Thanksgiving
*** Next week: 1.35.0-wmf.8 - group1 + group2
* RelEng blocking Product Infrastructure: to create node10/buster images
for Proton service migration [[phab:T237911]]
* Biggest fundraising campaign of the year hits enwiki (and in Canada also
frwiki) on Dec 2. Let's keep CentralNotice stable!
== Product ==
=== Android native app ===
* Updates:
** Suggested Edits v3 features and fundraising banner updates are now live
in production.
** Working on mobile-html integration: [[phab:project/view/4318]]
=== Product Infrastructure ===
* Blocked by:
** RelEng: to create node10/buster images for Proton service migration
[[phab:T237911]]
* Updates:
** Maps:
*** Investigating new OSM replication engine [[phab:T238554]]
** Proton:
*** Moving Proton to debian buster, blocked on RelEng for node10/buster
images [[phab:T237911]]
=== Structured Data ===
* Blocking:
** Search Platform: Data dumps for SDC: [[phab:T221917]]
* Updates:
** finishing off computer-aided tagging
** finishing off Lua support
** finishing off blockers for structured data in dumps
** adding new input types
=== Inuka ===
* Updates:
** KaiOS app settings menu [[phab:T236265]] [[phab:T236312]]
[[phab:T236314]]
== Technology ==
=== Fundraising Tech ===
* Updates:
** Battening down the hatches for the December fundraiser
** CiviCRM
*** Fixing duplicate mailing event records imported from bulk mail house
*** Investigating weird output from audit file parser for backup credit
card processor
*** Adding UI buttons to send end-of-year rollup emails on demand
** CentralNotice
*** Reviewing and finishing up sub-national geotargeting
*** Still comparing stats between new and old data pipelines
** Paymentswiki
*** small tweaks to CSS and fraud filters
=== Core Platform ===
* Updates:
** Page history REST endpoints out on train
** "Endgame" API gateway planning
** MCR Schema conversion
=== Engineering Productivity ===
==== Release Engineering ====
* Blocking:
** Product Infrastructure: to create node10/buster images for Proton
service migration [[phab:T237911]]
* Updates:
** Train Health
*** Last week: no train because of team offsite
*** This week: 1.35.0-wmf.8 - [[phab:T233856]] - group0 only because of
Thanksgiving
*** Next week: 1.35.0-wmf.8 - [[phab:T233856]] - group1 + group2
=== Search Platform ===
* Blocked by:
** Structured Data: Data dumps for SDC: [[phab:T221917]]
* Updates:
** Log Wikidata Query Service queries (sparql) to the event gate
infrastructure [[phab:T101013]] (soon to be deployed)
** Increase logging sampling rates for search metrics from 12.5% to 100%
(8x) [[phab:T197129]]
Hi All,
Is there any documentation or Gadget I can have a quick look at yo be able
to learn how to enable translation in gadgets?
Thanks in advance.
—
Eugene233
Hello all,
This message is important to everyone running an instance of Wikibase
including the Query Service GUI.
We just released a new version of the Wikidata Query Service GUI. This
release is primarily to fix several security issues described in T238822
<https://phabricator.wikimedia.org/T238822> and T238824
<https://phabricator.wikimedia.org/T238824> (these tasks will be made
public soon). These are different from the previous fix we deployed on
November 7th. The fix has been successfully deployed for the Wikidata Query
Service.
In order to keep your instance safe, please make sure to update your Query
Service GUI!
Git repositories, releases and currently active version docker images also
include the latest fixed code (see links below). If you have a local test
setup using the docker-compose example then see:
https://gist.github.com/addshore/36f8d6fe2331d28ca8f70df5abda20fd
Gerrit repositories:
-
https://gerrit.wikimedia.org/r/#/c/wikidata/query/gui/+/553311/
-
https://gerrit.wikimedia.org/r/#/c/wikidata/query/gui-deploy/+/553313/
Docker images:
-
latest: digest:
sha256:6570acb916b429f10ccb3bf3479b66aa6697b3fb3982166a09aba87eeaba7c90
-
legacy: digest:
sha256:4503257bbe1744ce389f07f6dcbaf53db7569cc3e570e30dd5a85c8d0073a39d
If you have any questions or issues updating your code, please let us know
(you can write me an email, or ask in the Wikibase Telegram group
<https://t.me/joinchat/HGjGexZ9NE7BwpXzMsoDLA>)
Thanks for your understanding,
Cheers,
--
Léa Lacroix
Project Manager Community Communication for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hey,
Since it's still Tuesday in some parts of the Pacific ocean, I want to
start the thread of Thank you Tuesday for this week [1] by thanking James
Forrester for working on improving production mediawiki configs that
reached an important milestone yesterday [2] This work is extremely
important not just because of migration to containers but also because it
makes our systems less prone to breakage. Thank you James.
[1] We haven't done thank you Tuesdays for a long time now, we should do it
more often.
[2]
https://lists.wikimedia.org/pipermail/wikitech-l/2019-November/092816.html
Best
--
Amir Sarabadani (he/him)
Software engineer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
https://wikimedia.de
Unsere Vision ist eine Welt, in der alle Menschen am Wissen der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
https://spenden.wikimedia.de
Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hi all,
Further to my email from Nov 19 [1], here is the next update about
Parsoid/PHP deployment on the Wikimedia cluster.
As of today,
* Parsoid/PHP is serving Visual Editor (VE), Content Translation (CX),
and Mobile Content Service (MCS, used by the Android app) on group 0 and
group 1 wikis [2].
* Parsoid/PHP is serving Flow on group 0 wikis [2]. It will be deployed
to group 1 wikis on Monday, Dec 2.
* During the week of Dec 2, we plan to enable Parsoid/PHP on all group 2
wikis for VE, CX, MCS, and Flow.
* Linter output on all wikis is currently served by Parsoid/JS and will
be the last product to be switched over to Parsoid/PHP.
If you notice any problems, please flag it on T238928 [3] or file a phab
task and tag Parsoid-PHP.
You can follow the deployment schedule on T229015 [4].
Subbu (on behalf of the Parsing team).
[1]
https://lists.wikimedia.org/pipermail/wikitech-l/2019-November/092777.html
[2] https://wikitech.wikimedia.org/wiki/Deployments/One_week (info about
what wikis are in groups 0, 1, 2)
[3] https://phabricator.wikimedia.org/T238928
[4] https://phabricator.wikimedia.org/T229015
Hey all,
[Unless you're writing Wikimedia production MediaWiki-land configuration
changes, you can ignore this note.]
As part of my work on moving variant configuration in static files[0], I've
just merged and deployed a change to how dblists work. They are now
auto-generated at merge time[1] (except for the very few lists which are
live-computed in production, which remain). The lists are calculated from
the per-wiki YAML files in wmf-config/config (and if you try to change the
dblist files manually, CI will error at you).
Changes to dblist memberships are quite rare, and this will enforce that we
don't make mistakes. (As part of this deployment, I removed three duplicate
entries and noted several irregularities we probably didn't intend.)
This means that if you're writing a change that previously would have meant
manually editing the dblist files, you now have to touch the YAML file
instead (and run composer build locally, or use CI to tell you what to
change).
This mostly affects the creation of new wikis (which should now be slightly
simpler), plus a few major features currently enabled through dblists. For
an example, if you were to remove FlaggedRevisions from Chechen Wikipedia,
you'd now need to edit cewiki.yaml[2] to remove the " - flaggedrevs" line,
as well as changes to InitialiseSettings.php.
This work unblocks some of the future re-architecting of config, which I've
mentioned before, as part of the long-term plan to move Wikimedia
production into containers. Configuration traits related to FR will inherit
from flaggedrevs.yaml, and static-like code in CommonSettings.php (and in
this case, flaggedrevs.php) can be significantly shrunk.
If anything has broken or has become, if you have any questions, or want to
talk about things, I'd be happy to discuss, here, on IRC, or on Phabricator.
Thanks!
[0] - https://phabricator.wikimedia.org/T223602
[1] - https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/545411
[2] -
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/…
Yours,
--
*James D. Forrester* (he/him <http://pronoun.is/he> or they/themself
<http://pronoun.is/they/.../themself>)
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello,
We have requested a 30 minutes read-only window for s7 (T238046) for the
26th November from 06:00-06:30 AM UTC to switchover that section primary
database master (T238044)
db1062 is an old host and out of warranty that will be decommissioned
(T217396). The new master will be db1086
We are going to do this on Tuesday 26th Nov from 06:00 to 06:30 AM UTC (we
do not expect to use the 30 minutes window, if everything goes as expected).
Impact: Writes will be blocked on the following wikis:
arwiki
cawiki
eswiki
fawiki
frwiktionary
hewiki
huwiki
kowiki
metawiki
rowiki
ukwiki
viwiki
Reads will remain unaffected.
This also includes centralauth database, which means some operations might
fail during the read-only period, such as: GlobalRenames,
Changing/Confirming emails, logging into new wikis, password changes...
Communication will happen at #wikimedia-operations
If you are around at that time and want to help with the monitoring, please
join us!
Thanks
Hi all,
A high volume of error messages in production logs can make
it hard to glance at error logs after a deployment and
reason about the deployment's impact.[0] This recurring mail
is part of an ongoing effort to reduce log noise.
At present I'm aware of three unresolved-but-tracked issues
which are causing a fair amount of noise:
* https://phabricator.wikimedia.org/T143756
** UnresolvedRedirectException in EntityAccessor::getEntity
(scribunto)
** ~8000 occurrences today
* https://phabricator.wikimedia.org/T226751
** PHP error "non well formed numeric value encountered" from
FormatMetadata->formatCoords
** ~600 occurrences today
* https://phabricator.wikimedia.org/T239165
** PHP Warning: count(): Parameter must be an array or an
object that implements Countable in WikibaseMediaInfo
** ~120 occurrences today
As ever, help in eliminating these errors from production
logs is greatly appreciated.
As a procedural note, I'm sending this early in the week due
to the Thanksgiving holiday. We'll be releasing 1.35.0-wmf.8 to
group 0 tomorrow (Tuesday) and then pausing there until
2019-12-04.
[0].
https://wikitech.wikimedia.org/wiki/Deployments/Holding_the_train#Logspam
--
Brennen Bearnes (he/him)
Release Engineering
Wikimedia Foundation