🚂🌈Summary of 1.38.0-wmf.16 train deployment
This email is a summary of the Wikimedia production deployment of
1.38.0-wmf.16
*wmf.16* is in production across all wikis and I'll be handing the
conductor hat to Dan for *wmf.17* which starts rolling today.
- Conductor: Mukunda Modell
- Backup Conductor: Antoine "hashar" Musso
- Blocker Task: T293957 <https://phabricator.wikimedia.org/T293957>
- Current Status <https://versions.toolforge.org>
📈 Stats
Stats for this train compared to the last 5 trains.
- 483 patches ▁▃▂▂█
- 0 Rollbacks █▆▃▆▁
- 1 Days of delay ▆█▁▂▂
- 4 Blockers ▁█▇▅▄
🎉 Traintastic Folks 🎉 Thanks to folks who reported or resolved blockers:
- Samuel
- Urbanecm
- James D. Forrester
- Timo Tijhof
- Ed Sanders
The Search Platform Team
<https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> usually holds
office hours the first Wednesday of each month—though we're going to have
them a week later this month. Come talk to us about anything related to
Wikimedia search, Wikidata Query Service, Wikimedia Commons Query Service,
etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, January 12th, 2022
Time: 16:00-17:00 GMT / 08:00-09:00 PST / 11:00-12:00 EST / 17:00-18:00 CET
& WAT
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vgj-bbeb-uyi
Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927
Hope to talk to you in a week!
—Trey
Trey Jones
Staff Computational Linguist, Search Platform
Wikimedia Foundation
UTC–5 / EST
Hi!
I just published the first version of a Go package which provides
utilities for processing
Wikidata entities JSON dumps and Wikimedia Enterprise HTML dumps. It
processes them in parallel on multiple cores, so processing is rather
fast. I hope it will be useful to others, too.
https://gitlab.com/tozd/go/mediawiki
Any feedback is welcome.
Mitar
--
http://mitar.tnode.com/https://twitter.com/mitar_m
MediaWiki has an experimental configuration flag $wgUseCategoryBrowser that
alters the appearance of categories. If you don't use this flag or are not
aware of it you can safely ignore this message.
We plan to remove this configuration flag and associated code in MediaWiki
1.38 without deprecation warnings given its experimental nature:
https://phabricator.wikimedia.org/T298553
If needed an extension can provide the same functionality, so if anyone
needs this functionality please let us know by replying to this email or
the Phabricator ticket to help guide us better.
Thanks for reading
Jon
Hello,
If you don’t use tendril.wikimedia.org or dbtree.wikimedia.org, feel free
to ignore this message.
As of today, tendril is now retired and the main page is replaced with a
list of replacement for different services tendril used to provide:
-
For checking out our dbtree and replication data:
-
if you are in the NDA LDAP group, use Orchestrator
<https://orchestrator.wikimedia.org>
-
otherwise, use the information page <https://noc.wikimedia.org/db.php>
on noc.wikimedia.org. For more detail you can also check eqiad.json
<https://noc.wikimedia.org/dbconfig/eqiad.json> or codfw.json
<https://noc.wikimedia.org/dbconfig/codfw.json>
-
If you are looking for slow queries log, go to slow queries dashboard
<https://logstash.wikimedia.org/app/dashboards#/view/43fcccd0-4df5-11ec-81e9…>
using our standard observability platform (logstash) (NDA required)
Tendril has been a great tool for us during the years, but unfortunately it
is impossible to maintain with modern MariaDB versions (it uses TokuDB,
which is no longer available on MariaDB after 10.1 and needs to be compiled
separately) nor its webservice is compatible with modern php versions. Its
database is still running on Stretch and on MariaDB 10.1 (which has not
been supported for a year already) and it is having serious scalability
issues. This would unblock us from removing a lot of legacy home-brew craft
and replace them with more modern toolings such as orchestrator
<https://orchestrator.wikimedia.org>.
Orchestrator has been in place for a few months now, and provides us with a
great way to see and (in the future) manage replication topologies. For now
we are using it only for visualization purposes but in the future we’d like
it to also help us to handle replication changes (it can be done from the
UI or via CLI) and recover topologies automatically if they fail and
involve masters or intermediate masters.
The slow queries dashboard
<https://logstash.wikimedia.org/app/dashboards#/view/43fcccd0-4df5-11ec-81e9…>
in logstash offer multiple advantages over tendril. You can set the
threshold to see slow queries that took longer to run. You can filter out
code paths you’re not interested in or zoom in to relevenet code paths. You
can limit it to write queries or read queries only. Also, it provides id of
the request making the slow query, so you can cross check it with the rest
of logstash or hadoop to identify problematic behavior.
If you need it for the transition period, you can still access it in
tendril-legacy.wikimedia.org. But it will be shut down in a month. You can
follow the work of shutting down tendril in
https://phabricator.wikimedia.org/T297605.
Thank you.
Well, hello.
Sharing random numbers from that past Gregorian calendar year 2021 with
you. Big thanks to all technical contributors! <3
=== Phabricator 2021 ===
* 27432 tasks got created.
* 24723 tasks got closed.
* 3746 people were active in Phabricator.
* 2171 people created tasks.
* 787 people closed tasks.
* The 20 people who created the most tasks:
ppelberg 426
Reedy 379
Lucas_Werkmeister_WMDE 374
Legoktm 355
Jdlrobson 336
Jdforrester-WMF 324
RobH 304
Aklapper 271
Inductiveload 256
Addshore 244
dcaro 244
Majavah 232
bd808 232
DVrandecic 231
cmassaro 215
kostajh 215
kai.nissen 212
Krinkle 200
Michael 196
DannyS712 195
* The 20 people who closed the most tasks:
Aklapper 981
Addshore 672
Jdlrobson 583
Jdforrester-WMF 580
Jopparn 558
Etonkovidova 546
ppelberg 490
Urbanecm 466
Krinkle 374
Lucas_Werkmeister_WMDE 340
hashar 333
Reedy 332
Samwalton9 321
LGoto 314
Legoktm 309
Xqt 294
ovasileva 288
kai.nissen 268
Gehel 255
matmarex 251
=== Gerrit 2021 ===
* 54097 changesets got created. [1]
* 98771 code reviews took place. [2]
* 586 people created patches. [3]
* The 20 people who submitted the most changesets: [4]
Umherirrender 2609
Robert Vogel 1319
DannyS712 1265
Zabe 1251
Legoktm 1241
Jforrester 1237
Jbond 1225
Reedy 1198
Urbanecm 1147
Pwirth 1032
Lucas Werkmeister (WMDE) 966
Xqt 920
Eileen 901
Ladsgroup 901
Thiemo Kreuz (WMDE) 897
Andrew Bogott 745
Elukey 715
Marostegui 703
Muehlenhoff 684
Dzahn 682
* The 20 people who reviewed the most patchsets: [5]
Jforrester 4176
Jbond 4045
DannyS712 3855
Robert Vogel 3119
Umherirrender 2986
Kunal Mehta 2516
Moritz Muehlenhoff 2231
Luca Toscano 2223
Daniel Zahn 2144
Patric Wirth 1823
Andrew Bogott 1811
Marostegui 1713
Martin Urbanec 1709
Filippo Giunchedi 1602
Ppchelko 1526
Andrew Otto 1482
Jon Robson 1378
aborrero 1327
Timo Tijhof 1289
Giuseppe Lavagetto 1252
If you find a bug in these numbers, please see
https://www.mediawiki.org/wiki/Community_metrics
Cheerio,
andre
[1] See "Gerrit 🡒 Changesets" on "Gerrit 🡒 Overview": https://wikimedia.biterg.io/goto/c2b4d03d9afadd08b1e1a5df87071276
[2] See "Total Number of Code Reviews 🡒 Approvals" on "Gerrit 🡒 Approvals": https://wikimedia.biterg.io/goto/e055063561a4880db0a65c4727cdf919
[3] See "Gerrit 🡒 Changeset Submitters" on "Gerrit 🡒 Overview": https://wikimedia.biterg.io/goto/c2b4d03d9afadd08b1e1a5df87071276
[4] See "Submitters" on "Gerrit 🡒 Overview": https://wikimedia.biterg.io/goto/c2b4d03d9afadd08b1e1a5df87071276
[5] See "Approvals by Reviewer" on "Gerrit 🡒 Approvals": https://wikimedia.biterg.io/goto/e055063561a4880db0a65c4727cdf919
--
Andre Klapper (he/him) | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/
Hi Asaf,
That's a good response, but I'm not sure it provides a practical way
forward. How can volunteers bring this issue to the attention of the WMF
leadership to get the allocation of the time of Wikimedia staff who can
take ownership implement changes here?
Presumably emails on these lists have relatively little impact at the
most senior levels, so they aren't a good way forward - and similarly on
Phabricator.
The Wishlist provides a way of showcasing issues and a relatively clear
way forward to get them implemented, but with really limited capacity.
How would a case for technical support be made apart from that? It's not
clear if a simple survey would be sufficient. Would an RfC and
discussion on meta help? Does it need the media to be involved to make
it a public crisis? Or should it be proposed as a grant request, perhaps
for a Wikimedia affiliate to implement? Or is there another avenue that
could be persued? Bearing in mind that there's no practical way for
community members to propose changes to the WMF annual plan for multiple
years now.
Sorry to defocus things and express more frustration, but I think there
should be a clear way forward with this type of issue, which isn't
obvious right now. Personally, my hopes are on the Wishlist, although
I'll be reposting a 14-year-old issue there for the fifth time when that
process opens on the 10th January...
Thanks,
Mike
On 1/1/22 20:10:43, Asaf Bartov wrote:
> Writing in my volunteer capacity:
>
> On Sat, 1 Jan 2022, 08:43 Amir Sarabadani <ladsgroup(a)gmail.com
> <mailto:ladsgroup@gmail.com>> wrote:
>
>
> Honestly, the situation is more dire than you think. For example,
> until a couple months ago, we didn't have backups for the media
> files. There was a live copy in the secondary datacenter but for
> example if due to a software issue, we lost some files, they were
> gone. I would like to thank Jaime Crespo for pushing for it and
> implementing the backups.
>
> But I beat my drum again, it's not something you can fix overnight.
> I'm sure people are monitoring this mailing list and are aware of
> the problem.
>
>
> [My goal in this post is to ficus effort and reduce frustration.]
>
> Yes, people reading here are aware, and absolutely none of them expects
> this (i.e. multimedia technical debt and missing features) to be fixed
> overnight.
>
> What's lacking, as you pointed out, is ownership of the problem. To own
> the problem, one must have *both* technical understanding of the issues
> *and* a mandate to devote resources to addressing them.
>
> It is this *combination* that we don't have at the moment. Lots of
> technical people are aware, and some of them quite willing to work
> toward addressing the issues, but they are not empowered to set
> priorities and commit resources for an effort of that scale, and the
> problems, for the most part, don't easily lend themselves to volunteer
> development.
>
> It seems to me there are *very few* people who could change status quo,
> not much more than a handful: the Foundation's executive leadership (in
> its annual planning work, coming up this first quarter of 2022), and the
> Board of Trustees.
>
> Therefore, the greatest contribution the rest of us could make toward
> seeing this work get resourced is to help make the case to the
> executives (including the new CEO, just entering the role) with clear
> and compelling illustrations of the *mission impact* of such investment.
> In parallel, interested engineers and middle managers could help by
> offering rough effort estimates for some components, a roadmap, an
> overview of alternatives considered and a rationale for a recommended
> approach, etc.
>
> But this would all be preparatory and supporting work toward *a
> resourcing decision* being made. So long as such a decision isn't made,
> no significant work on this can happen.
>
> Finally, while it is easy to agree that *this* is necessary and useful
> on its own, to actual resource it in the coming annual plan it would be
> necessary to argue that it is *more* useful and necessary than some
> *other* work, itself also necessary and useful.
>
> Another thing that may help is being explicit about just how important
> this is, even literally saying things like "this would have far more
> impact on our X goal than initiative A, B, or C", naming actual
> resourced or potentially resourced things. It is sometimes difficult for
> managers who aren't practicing Wikimedia volunteers to assess just how
> necessary different necessary things are, from different community
> perspectives.
>
> And of course, one such opinion, or a handful, would not be a solid base
> for resourcing decisions, so perhaps a large-scale ranking survey of
> some sort would be helpful, as SJ implicitly suggested in the original post.
>
> Cheers,
>
> A.
> (In my volunteer capacity)
>
> _______________________________________________
> Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
> To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org