Lis ton message de Nganguem Victor avant qu'il ne soit effacé!
Pour lire ton message, suis simplement ce lien:
http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6
D'autres personnes sont aussi présentes:
Oded (Tel Aviv, Israël)
Priya (Udaipur, Inde)
RajaYogi BK (Udaipur, Inde)
Karuna (Udaipur, Inde)
Chika Reginald Onyia (Pnompen', Cambodge)
...Qui d'autre?
http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6
Les liens ne fonctionnent pas dans ce message? Copie les dans la barre d'adresse de ton navigateur.
Tu as reçu cet email suite à un message envoyé par Nganguem Victor de notre système. S'il s'agit d'une erreur, ignore simplement cet email. La requête sera alors effacée du système.
Amuse-toi bien !
L'équipe Badoo
Courrier automatique de Badoo suite à l'envoi d'un message à ton attention sur Badoo. Les réponses ne sont ni stockées, ni traitées. Si tu ne veux plus recevoir de message de Badoo, fais-le nous savoir:
http://eu1.badoo.com/impersonation.phtml?lang_id=6&mail_code=65&email=media…
Hello All,
Welcome to the second edition of the monthly MediaWiki Insights
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports> email!
Since the beginning of July, the Foundation has dedicated MediaWiki product
leadership and a new MediaWiki engineering group
<https://www.mediawiki.org/wiki/MediaWiki_Engineering_Group>.
In August
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/August_20…>,
we’ve shared a broad overview on the focus for the next few quarters:
1. Building up the new MW Engineering group and MW Product function
2. Developing a strategy for MediaWiki - by June 30th, 2024 [WMF Annual
Plan, WE3
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/…>
]
3. Reaching a 20% increase of authors to selected MediaWiki repositories
deployed in Wikimedia production - by June 30th, 2024 [WE3.2]
4. Investing in developer experiences and reduce fragmentation of
developer workflows [WE 3.1] - continuous work with specific deliverables
in 2023/24
5. Exploring and resolving a set of questions around stewardship and
Open Source strategy (goes beyond MediaWiki) [WE3.3]
We’re still in the process of “settling in” (1.), but also made progress on
a few things that we wanted to start tackling early:
Stewardship
We’ve had conversations within the MediaWiki Engineering group
<https://www.mediawiki.org/wiki/MediaWiki_Engineering_Group> on which
components we should prioritize initially/own directly and what the things
are that we’d primarily provide guidance on. While this is work in progress
and also touches on bigger questions, one notable decision is that MW
Engineering takes on stewardship for the authentication-related components
(in MW core and extensions), with support from the Security team. We’ve
resolved outstanding code stewardship requests for the CentralAuth
<https://phabricator.wikimedia.org/T252244> and Oauth
<https://phabricator.wikimedia.org/T224919> extensions as a consequence of
this decision. These changes and other updates are reflected on the developers
and maintainers page <https://www.mediawiki.org/wiki/Developers/Maintainers>
on MW.org.
MediaWiki within Wikimedia’s ecosystem: Update on interviews
So far we’ve interviewed about 40 people on their experiences with
MediaWiki within Wikimedia’s ecosystem and plan a few more interviews. We
expect to be able to wrap up this first round of research in October and to
share the outcome and conclusions in November. These conversations have
been incredibly helpful - many thanks to all the people who took the time
to share their thoughts or still will do so <3
You can find a tentative timeline and overview on research planned
throughout the next few quarters on this page
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights#Research_pillars_…>
.
Project snapshot: Source Maps and top-level autologin
Over the past few weeks, the MediaWiki Engineering group has been working
on a mix of onboarding tasks (i.e. ResourceLoader, ActionAPI, CentralAuth),
production errors, long term initiatives (Parsoid Read Views, RESTBase
deprecation), consultancy, code review for staff and volunteers’ patches,
and completed projects that had been in the making for a while. A few
snapshots:
Source Maps <https://web.dev/source-maps/> aim to make debugging in web
development easier. It’s a technique for mapping combined and minified
JavaScript back to the original files. Support for source maps is now
implemented in ResourceLoader
<https://www.mediawiki.org/wiki/ResourceLoader>, to aid with debugging
ResourceLoader in production. You can learn more about this work in this
ticket. <https://phabricator.wikimedia.org/T47514> <3 to Tim, Timo and
others for their work on this!
Browsers increasingly roll out anti-tracking measures and limitations on
third-party cookie use. An unfortunate side effect of this is that it also
impacts CentralAuth autologin. One way to mitigate the effects and to allow
auto-login when the browser blocks third-party cookies is to attempt
central auto-login via top-level navigation. This has been enabled in
September. You can learn more about this work in this ticket
<https://phabricator.wikimedia.org/T326281>. <3 to Gergö and others for the
work on this!
Onboarding, among other means, has continued via the weekly Code Mob
sessions: Check out the recordings on this page
<https://meta.wikimedia.org/wiki/User:BPirkle_(WMF)/Code_Mobs_2023> if you
want to follow along.
Next: Enable more people to know MediaWiki and contribute effectively
A key question this year is how we can grow the number of people willing
and able to contribute to MediaWiki. So far we’ve explored approaches and
focus areas, turned some aspects of this already into active practice
through code review and consultancy for teams whose projects touch
MediaWiki core; and came up with first ideas that may help new MediaWiki
contributors (example <https://phabricator.wikimedia.org/T347347>).
We’ll be sharing more about this work and possible initiatives in October,
which is when we “officially” start with working towards an increase of
authors across a specific set of MW repositories that are deployed to
production (WMF Annual Plan, WE3.2
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/…>
).
Thanks all for reading! - Have a great weekend,
Birgit
--
Birgit Müller (she/her)
Director of Product, MediaWiki and Developer Experiences
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi all,
On Thursday we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
- 1.35.12
- 1.39.5
- 1.40.1
This will resolve four security issues in MediaWiki core, two in a bundled
skin, along with bug fixes included for maintenance reasons. This includes
various patches for PHP 8.0, PHP 8.1 and PHP 8.2 support.
One issue in a bundled skin only affects MediaWiki 1.40 and master, the
other bundled skin issue affects MediaWiki 1.39, 1.40 and master.
A partial fix for one of the skin issues is already merged into the
relevant release branch.
One more minor security fix was merged in public after the releases of
1.35.11/1.38.7/1.39.4/1.40.0.
We will make the fixes available in the respective release branches and
master in git. Tarballs will be available for the above mentioned point
releases as well.
A summary of some of the security fixes that have gone into non-bundled
MediaWiki extensions will also follow later.
As a reminder, when 1.35 was released, it was originally due to become end
of life (EOL) at the end of September 2023. Due to 1.39 being released late
(November 2022), and to honor the commitment to the 1 year overlap of
MediaWiki LTS releases, this formal EOL process is being delayed till at
least the end of November 2023.
In practice, this may become sometime in December 2023, to coincide with
the security and maintenance release for that quarter. A formal EOL
announcement for 1.35 will come in advance of that point.
It is therefore expected that 1.35.13 in December 2023 will become the
final release for the 1.35 branch.
It is noted that support and CI for 1.35 is becoming more limited;
backports are becoming best-effort. Browser testing has been dropped for
1.35 in Wikimedia CI, due to the difficulties to support this.
It is strongly recommended to upgrade to 1.39 (the next LTS after 1.35),
which will be supported until November 2025, or 1.40, which will be
supported until June 2024.
[1] https://www.mediawiki.org/wiki/Version_lifecycle
Hey all,
This is a quick note to highlight that in six weeks' time, the REL1_41
branch will be created for MediaWiki core and each of the extensions and
skins in Wikimedia git, with some (the 'tarball') included as sub-modules
of MediaWiki itself[0]. This is the first step in the release process for
MediaWiki 1.41, which should be out in May 2023, approximately six months
after MediaWiki 1.40.
The branches will reflect the code as of the last 'alpha' branch for the
release, 1.41.0-wmf.30, which will be deployed to Wikimedia wikis in the
week beginning 10 October 2023 for MediaWiki itself and those extensions
and skins available there.
After that point, patches that land in the main development branch of
MediaWiki and its bundled extensions and skins will be instead be slated
for the MediaWiki 1.42 release unless specifically backported[1].
If you are working on a new feature that you wish to land for the release,
you now have a few days to finish your work and land it in the development
branch; feature changes should not be backported except in an urgent case.
If your work might not be complete in time, and yet should block release
for everyone else, please file a task against the `mw-1.41-release` project
on Phabricator.[2]
If you have tickets that are already tagged for `mw-1.41-release`, please
finish them, untag them, or reach out to get them resolved in the next few
weeks.
We hope to issue the first release candidate, 1.41.0-rc.0, two weeks after
the branch point, and if all goes well, to release MediaWiki 1.41.0 a few
weeks after that.
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
[0]: <https://www.mediawiki.org/wiki/Bundled_extensions_and_skins>
[1]: <https://www.mediawiki.org/wiki/Backporting_fixes>
[2]: <https://phabricator.wikimedia.org/tag/mw-1.41-release/>
Hello,
The Wikimedia Foundation Research team [0] is committed to serving
Wikimedia volunteer developers so that they can effectively leverage the
expertise of the Wikimedia research community to contribute to Wikimedia
projects.
We refer to a Wikimedia volunteer developer as any person who contributes
to a piece of software in the Wikimedia ecosystem, e.g., MediaWiki
extensions, desktop and mobile apps and services, bots, PAWS notebooks,
user scripts, etc.
If you identify yourself as a Wikimedia volunteer developer, your
participation in this brief survey [1] would be very relevant for our team
to identify existing and suggested research needs and opportunities of the
Wikimedia developer community.
Thank you for your time and consideration.
Kinneret Gordon, Pablo Aragón and Leila Zia
On behalf of the Wikimedia Research team
[0] https://research.wikimedia.org
[1] https://wikimediafoundation.limesurvey.net/developers-research-needs
--
Kinneret Gordon
Lead Research Community Officer
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi Everyone,
I was looking at our Special:Version page, and got to thinking about
api.php [1] and rest.php.[2] I don't believe anyone on our team is
using the APIs, and I would like to disable them to reduce attack
surface. Or disable them on external interfaces (or maybe allow on
localhost/127.0.0.1).
I see api.php can be disabled via $wgEnableAPI.[1] But I don't see a
similar option for rest.php.[2]
I have two questions. First, is it possible to disable api.php and
rest.php in practice? Or restrict them to internal interfaces only?
Second, what option controls rest.php?
And maybe a third question, can we rename api.php and rest.php tosay,
api.php.unused and rest.php.unused? Will that produce ill effects?
Thanks in advance.
[1] https://www.mediawiki.org/wiki/Manual:Api.php
[2] https://www.mediawiki.org/wiki/Manual:Rest.php