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
On Thu, Dec 30, 2021, 10:27 AM Samuel Klein <meta.sj(a)gmail.com> wrote:
> Separate thread. I'm not sure which list is appropriate.
> *... but not all the way to sentience
> <https://en.wikipedia.org/wiki/The_Uplift_War>.*
>
> The annual community wishlist survey (implemented by a small team,
> possibly in isolation?) may not be the mechanism for prioritizing large
> changes, but the latter also deserves a community-curated priority queue.
> To complement the staff-maintained priorities in phab ~
>
> For core challenges (like Commons stability and capacity), I'd be
> surprised if the bottleneck were people or budget.
>
Currently there are zero people and no budget for multimedia, aside from
whatever work I and others manage to get done here there. And I'm afraid I
don't scale.
It's Wikimedia Foundation's job to assign budget and people here. I've been
hoping for years that this will happen, and continue to hope.
-- brion
We do need a shared understanding of what issues are most important and
> most urgent, and how to solve them. For instance, a way to turn Amir's
> recent email about the problem (and related phab tickets) into a family of
> persistent, implementable specs and proposals and their articulated
> obstacles.
>
> An issue tracker like phab is good for tracking the progress and
> dependencies of agreed-upon tasks, but weak for discussing what is
> important, what we know about it, how to address it. And weak for
> discussing ecosystem-design issues that are important and need persistent
> updating but don't have a simple checklist of steps.
>
> So where is the best current place to discuss scaling Commons, and all
> that entails? Some examples from recent discussions (most from the wm-l
> thread below):
> - *Uploads*: Support for large file uploads / Keeping bulk upload tools
> online
> - *Video*: Debugging + rolling out the videojs
> <https://phabricator.wikimedia.org/T248418> player
> - *Formats*: Adding support for CML
> <https://phabricator.wikimedia.org/T18491> and dozens of other
> <https://phabricator.wikimedia.org/T297514> common high-demand file
> formats
> - *Thumbs*: Updating thumbor <https://phabricator.wikimedia.org/T216815>
> and librsvg <https://phabricator.wikimedia.org/T193352>
> - *Search*: WCQS still <https://phabricator.wikimedia.org/T297454> down
> <https://phabricator.wikimedia.org/T297454>, noauth option
> <https://phabricator.wikimedia.org/T297995> wanted for tools
> - *General*: Finish implementing redesign
> <https://phabricator.wikimedia.org/T28741> of the image table
>
> SJ
>
> On Wed, Dec 29, 2021 at 6:26 AM Amir Sarabadani <ladsgroup(a)gmail.com>
> wrote:
>
>> I'm not debating your note. It is very valid that we lack proper support
>> for multimedia stack. I myself wrote a detailed rant on how broken it is
>> [1] but three notes:
>> - Fixing something like this takes time, you need to assign the budget
>> for it (which means it has to be done during the annual planning) and if
>> gets approved, you need to start it with the fiscal year (meaning July
>> 2022) and then hire (meaning, write JD, do recruitment, interview lots of
>> people, get them hired) which can take from several months to years. Once
>> they are hired, you need to onboard them and let them learn about our
>> technical infrastructure which takes at least two good months. Software
>> engineering is not magic, it takes time, blood and sweat. [2]
>> - Making another team focus on multimedia requires changes in planning,
>> budget, OKR, etc. etc. Are we sure moving the focus of teams is a good
>> idea? Most teams are already focusing on vital parts of wikimedia and
>> changing the focus will turn this into a whack-a-mole game where we fix
>> multimedia but now we have critical issues in security or performance.
>> - Voting Wishlist survey is a good band-aid in the meantime. To at least
>> address the worst parts for now.
>>
>> I don't understand your point tbh, either you think it's a good idea to
>> make requests for improvements in multimedia in the wishlist survey or you
>> think it's not. If you think it's not, then it's offtopic to this thread.
>>
>> [1]
>> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
>> [2] There is a classic book in this topic called "The Mythical Man-month"
>>
>> On Wed, Dec 29, 2021 at 11:41 AM Gnangarra <gnangarra(a)gmail.com> wrote:
>>
>>> we have to vote for regular maintenance and support for
>>> essential functions like uploading files which is the core mission of
>>> Wikimedia Commons
>>>
>> _______________________________________________
> Commons-l mailing list -- commons-l(a)lists.wikimedia.org
> To unsubscribe send an email to commons-l-leave(a)lists.wikimedia.org
>
Hello,
As of today, all requests to several special pages (and their API
counterparts) are subject to a maximum database query execution time of 30
seconds. These special pages are: RecentChanges, Watchlist, Contributions,
and Log. This limit has already been in place for one third of all requests
accessing these page types since December 16th.
This threshold is based on a sampling of half a million requests done to
these special pages by users (excluding crawlers) in three largest wikis
(English Wikipedia, Wikidata and Wikimedia Commons). Out of 500,000
requests only 64 were above thirty seconds and 38 (out of that 64) were
above 60s. This meant that while the database returned the result of the
query in those cases, due to the 60 second limit of the webservice workers,
no results were shown to the user. Our logs show that we have around 1000
requests taking more than thirty seconds (in database query time) per day
so the ratio is extremely small (We get around 10 billion requests per day).
Putting things in context, these queries, while being only 0.01% of the
total number of requests to those special pages, were responsible for 2.9%
of the load. In a few scenarios where such queries appeared at a higher
volume, they were a contributing factor in outages that made one or more
Wikimedia projects unavailable. If left as-is the current configuration is
a potential DDoS vector (and likely was weaponized as one).
Even though ~1000 requests a day is not much, I understand that it is an
inconvenience and it might break useful workflows for some people (for
example patrollers). Query timeout doesn’t mean your request is bad, it
means our database schemas need improvements. We are aware of some of these
needed improvements and we are working on it but migrating terabytes of
data that needs to be replicated to twenty different servers while serving
millions of queries per second is not easy and will take time.
In the meantime, if this is breaking your workflow, please use
https://quarry.wmcloud.org or build a tool in Toolforge (it has access to
database replicas with a much higher timeout) to accommodate. For more
information, see:
https://wikitech.wikimedia.org/wiki/Help:Toolforge/Database
If you need advice on writing the queries. Feel free to create a ticket
with the “Data-Persistence (Consultation)” tag and we would be happy to
help.
For similar reasons the DynamicPageList extension has had a query limit of
10 seconds (due to its history of causing major issues
<https://phabricator.wikimedia.org/T287380>) since December 16.
Unfortunately, this doesn’t mean it’s safe to enable DPL on more wikis.
For more information, you can take a look at the ticket:
https://phabricator.wikimedia.org/T297708
Thank you
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
I am pleased to announce that Wikimedia Enterprise's HTML dumps [1] for
October 17-18th are available for public download; see
https://dumps.wikimedia.org/other/enterprise_html/ for more information. We
expect to make updated versions of these files available around the 1st/2nd
of the month and the 20th/21st of the month, following the cadence of the
standard SQL/XML dumps.
This is still an experimental service, so there may be hiccups from time to
time. Please be patient and report issues as you find them. Thanks!
Ariel "Dumps Wrangler" Glenn
[1] See https://www.mediawiki.org/wiki/Wikimedia_Enterprise for much more
about Wikimedia Enterprise and its API.
Hello cloud-vps users,
There are still about 84 unclaimed projects at
https://wikitech.wikimedia.org/wiki/News/Cloud_VPS_2021_Purge
Please take a moment to look at that page and mark projects that you are
using.
Unclaimed projects will be in danger of shutdown on February 1st, 2022.
Thank you to those of you who have already acted on this.
Thank you!
- Komla
-------- Forwarded Message --------
Subject: Cloud VPS users, please claim your projects (and, introducing
Komla)
Date: Thu, 2 Dec 2021 14:42:08 -0600
From: Andrew Bogott <abogott(a)wikimedia.org> <abogott(a)wikimedia.org>
Reply-To: abogott(a)wikimedia.org
Organization: The Wikimedia Foundation
To: Cloud-announce(a)lists.wikimedia.org
CC: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
<wikitech-l(a)lists.wikimedia.org>
Hello cloud-vps users!
It's time for our annual cleanup of unused projects and resources. Our new
developer advocate Komla Sapaty will be guiding this process; please
respond promptly to his emails and do your best to make him feel welcome!
Every year or so the Cloud Services team tries to identify and clean up
unused projects and VMs. We do this via an opt-in process: anyone can mark
a project as 'in use,' and that project will be preserved for another year.
I've created a wiki page that lists all existing projects, here:
https://wikitech.wikimedia.org/wiki/News/Cloud_VPS_2021_Purge
If you are a VPS user, please visit that page and mark any projects that
you use as {{Used}}. Note that it's not necessary for you to be a project
admin to mark something -- if you know that you're currently using a
resource and want to keep using it, go ahead and mark it accordingly. If
you /are/ a project admin, please take a moment to mark which VMs are or
aren't used in your projects.
When February arrives, I will shut down and begin the process of reclaiming
resources from unused projects.
If you think you use a VPS project but aren't sure which, I encourage you
to poke around on https://tools.wmflabs.org/openstack-browser/ to see what
looks familiar. Worst case, just email cloud(a)lists.wikimedia.org with a
description of your use case and we'll sort it out there.
Exclusive toolforge users are free to ignore this email and future related
things.
Thank you!
-Andrew and the WMCS team
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2021-12): 263
Active Maniphest users (any activity) in (2021-12): 959
Task authors in (2021-12): 458
Users who have closed tasks in (2021-12): 254
Projects which had at least one task moved from one column to another on
their workboard in (2021-12): 258
Tasks created in (2021-12): 1617
Tasks closed in (2021-12): 1325
Open and stalled tasks in total: 49056
* Only open tasks in total: 48154
* Only stalled tasks in total: 902
Median age in days of open tasks by priority:
Unbreak now: 24
Needs Triage: 726
High: 1033
Normal: 1601
Low: 2210
Lowest: 2290
(How long tasks have been open, not how long they have had that priority)
Active Differential users (any activity) in (2021-12): 3
To see the names of the most active task authors:
* Go to https://wikimedia.biterg.io/
* Choose "Phabricator > Overview" from the top bar
* Adjust the time frame in the upper right corner to your needs
* See the author names in the "Submitters" panel
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on phab1001 at Sat 01 Jan 2022 12:00:28 AM UTC)