Best IPTV Service at an Affordable Price
Experience breathtaking 4K visuals on any device, at any place, at any time. Discover an expansive library with over 40,000 channels and more than 54,000 VOD options. Links : https://www.iptvservice.site/
Hi everyone,
This is an information only message. There is no action required.
We're excited to announce that Catalyst is now available in public beta on
Patchdemo!
Catalyst is an API that wraps a purpose-built CI Kubernetes cluster.
Patchdemo uses Catalyst to deploy demos in their own pods, separated from
other deployments. Catalyst adds isolation and an easier path forward to
scale as more people use it. In the future, Catalyst will enable more
complex testing topologies where, for instance, a service is needed
alongside MediaWiki to test an extension that relies on that service.
To kick the tires of the new Catalyst backend, you can visit
https://patchdemo.wmcloud.org and check the "Use experimental Kubernetes
backend" checkbox. The experience is mostly the same as the non-Catalyst
use-case, except you'll see that logs are streamed from Kubernetes.
During the public beta, this checkbox will default to being unchecked. We
are eagerly accepting feedback on our Phabricator board:
https://phabricator.wikimedia.org/tag/catalyst/ . You can also reach out on
IRC to kindrobot or thcipriani on #wikimedia-cloud. You can read more about
Catalyst at https://wikitech.wikimedia.org/wiki/Catalyst .
Best,
Stef Dunlap and the Catalyst team
--
*Stef Dunlap* (they/she)
Staff Software Engineer
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello and Happy New Year!
The quarterly Technical Community Newsletter for January 2025 is now
available:
https://www.mediawiki.org/wiki/Technical_Community_Newsletter/2025/January.
This quarterly newsletter contains highlights, news, blog posts, and
interesting information from and about the Wikimedia Technical Community.
The Wikimedia Technical Community is large and diverse, and we know we
can't capture everything. Got something you would like to see or something
you want to highlight in the next quarterly newsletter? Add your suggestion
to the talk page:
https://www.mediawiki.org/wiki/Talk:Technical_Community_Newsletter. We
would love to hear your ideas for future newsletters!
To help your email inbox keep up with the latest updates and information,
please subscribe to the Technical Community Newsletter:
https://www.mediawiki.org/wiki/Newsletter:Technical_Community_Newsletter.
Cheers,
Deb
--
deb tankersley (she/her)
developer outreach program management
Wikimedia Foundation
Hi all,
You're probably familiar with the mw.Api JavaScript class
<https://doc.wikimedia.org/mediawiki-core/master/js/mw.Api.html>
provided by MediaWiki, which can be used to make requests to our action API.
promise = ( new mw.Api() ).get( /*...*/ );
You may also know that the promises it returns are enhanced with an
.abort() method, which cancels the underlying HTTP request and rejects
the promise.
promise.abort();
The problem is that this method is only available on the original
promise object. If you try to chain promises, it no longer works:
promise.then( /*...*/ ).abort(); // Error: abort is not a function
Copying this method to the chained promise is very cumbersome. I will
spare you an example, but you can find it in the Phabricator task I
filed for this problem: T346984
<https://phabricator.wikimedia.org/T346984>. It's also not possible to
do if you use async/await, which we'll hopefully be able to use in
MediaWiki code soon.
The designers of the HTML5 Fetch API
<https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API> came up
with a different solution to the problem of cancelling HTTP requests:
abort signals
<https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#canc…>.
The Fetch API is increasingly being used outside of the MediaWiki world,
and so I would like to enhance our mw.Api to support the same approach.
*Here's my proposal:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/959350*
As you can tell by the six-digit patch number, I've had a hard time
finding anyone else interested in this, so I'm sending out this call for
reviewers. I hope there's someone out there with review rights who likes
the idea as well :)
You can read the documentation with examples of the new style here:
https://patchdemo.wmcloud.org/wikis/ee373520a4/w/docs/js/mw.Api-AbortContro…
The.abort() method is not being removed, and as a bonus, the patch
includes improved documentation for that style of cancellable promises:
https://patchdemo.wmcloud.org/wikis/ee373520a4/w/docs/js/mw.Api-AbortablePr…
--
Bartosz Dziewoński
Hi everyone,
Summary
After a long series of consultations with various teams in the Wikimedia
Foundation, I find myself happy to inform you of the sunset of an API from
the current Wikimedia offerings.
That would be *recommendation-api*, the one powering
*https://<project_domain>/api/rest_v1/#/Recommendation* family of
endpoints, e.g. https://commons.wikimedia.org/api/rest_v1/#/ or
https://en.wikipedia.org/api/rest_v1/#/Recommendation.
The codebase of that API resides in
*https://gerrit.wikimedia.org/g/mediawiki/services/recommendation-api
<https://gerrit.wikimedia.org/g/mediawiki/services/recommendation-api>*.
The removal date will be 2025-03-31.
There is some more information below as to why, what and how as well as an
estimation of the impact this is expected to have (minimal to zero). It is
also my intention to proceed with a diff <https://diff.wikimedia.org/> post
explaining our process in more detail.
Intro
Recommendation-api was being used solely by the Wikipedia official Android
application. Given that recently <https://phabricator.wikimedia.org/T373611>,
the Android Wikipedia Official application has moved away from using this
API, the SRE team wanted to remove this service from production to focus on
more impactful services. The problem was ensuring that we turn off this API
responsibly so that we do not have a significant impact on users who have
not yet upgraded their apps and do not waste SRE effort on supporting a
service we are moving away from, for more than we need to. A complication
was that the service wasn't anymore owned by anyone, meaning maintenance
(Node.js and Operating System upgrades) had to be carried out by people
that were not acquainted at all with the code base.
Process
To achieve the above goals, a process was jump started by a group of
Principal Engineers in the Foundation (Jon Robson, Moriel Schottlender and
yours truly) collecting data and feedback regarding the remaining usage of
the API as well as the estimated amount of effort that would be needed to
continue maintaining the service vs sunsetting it. Since October, we spoke
to various stakeholders in the Foundation to figure out the best possible
plan, going through a variety of possible paths. We ended up recommending
that the service be sunset at 2025-03-31, a recommendation that was
accepted.
Impact
The service is only accessed by users of the Wikipedia Android application.
Recent versions of it no longer rely on it and there will be zero (0)
impact on users of these. But users with application versions older than 6
months by the time of removal (2025-03-31), will see reduced functionality
in the form of the *Suggested Edits* part of the application no longer
functioning. The rest of the application will continue to function as
usual. We encourage users of versions older than *r/2.7.50504-r-2024-10-01
<https://github.com/wikimedia/apps-android-wikipedia/releases/tag/r%2F2.7.50…>*
to
update.
We wanted to make sure we don't break 3rd party users without giving them a
heads up. Going through access logs and metrics, we identified no valid 3rd
party users. Furthermore, we intend to review traffic/errors to that API 1
month past the cutoff date and evaluate the effectiveness of our solution.
Note
This API should not be confused with another one, also named
recommendation-api
<https://gerrit.wikimedia.org/r/plugins/gitiles/research/recommendation-api/>,
and exposed by LiftWing, under the
https://api.wikimedia.org/wiki/Lift_Wing_API/Reference/Get_content_translat…
endpoint.
The latter is powered by a different codebase and, conflicting naming
aside, has no other relation to the former or this sunsetting.
Regards,
--
Alexandros Kosiaris
Principal Site Reliability Engineer
Wikimedia Foundation
Hello there! I am writing to let you know that the third round of
community calls about Wikimedia Commons,[1] to help prioritize support
efforts from Wikimedia Foundation for the 2025-2026 Fiscal Year, will
take place next week.
Our next call will focus on tool investment priority. There are
constant calls from the community for the Foundation to adopt
community-made tools in order to maintain workflows for the
contributors that depend on them. The range of these tools varies
widely, and includes media upload (e.g. Video2Commons), editing (e.g.
CropTool), curation (e.g. Cat-a-lot) and metrics (e.g. BaGLAMa) tools.
Batch upload and metrics tools are said to be critical for the
affiliates and Wikimedians in Residence who partner with libraries and
other cultural institutions to illustrate Wikipedia. They need to be
able to contribute files efficiently at scale, and report on the
impact of these contributions. However, community surveys have
identified more than 30 different tools that are used for content
partnerships.
More specifically the questions will be:
1) Does it make sense for the Foundation to invest in supporting the
wide range of community-developed tools that don’t have active
maintainers, or should a smaller set of critical workflows be enabled
through new or improved features in core products?
2) Which tool would you recommend to prioritise? Something
community-facing or GLAM-facing or video-related or something else?
The call will take place at two different time slots:
* The first one will be on January 15, at 08:00 UTC,[2] and it will be
hosted on Zoom by Senior Director of Product Management Runa
Bhattacharjee; you can subscribe to it on Meta;[3]
* The second one will be on January 15, at 16:00 UTC,[4] and it will
be hosted on Zoom by Chief Product & Technology Officer Selena
Deckelmann; you can subscribe to it on Meta.[5]
If you cannot attend the meeting, you are invited to express your
point of view at any time you want on the Commons community calls talk
page.[6] We will also post the notes of the meeting on the project
page, to give the possibility to read what was discussed also to those
who couldn’t attend it.
If you want, you are invited to share this invitation with all the
people you think might be interested in this call.
We hope to see you and/or read you very soon!
Luca/Sannita
[1] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Commons_…
[2] https://zonestamp.toolforge.org/1736928000
[3] https://meta.wikimedia.org/wiki/Event:Commons_community_discussion_-_15_Jan…
[4] https://zonestamp.toolforge.org/1736956800
[5] https://meta.wikimedia.org/wiki/Event:Commons_community_discussion_-_15_Jan…
[6] https://commons.wikimedia.org/wiki/Commons_talk:WMF_support_for_Commons/Com…