As per the MediaWiki version lifecycle[1], I would like to announce the
formal end of life (EOL) of MediaWiki 1.31 as of tomorrow, Thursday
September 30, 2021, coinciding with the final security and maintenance
release for the branch, 1.31.16.
This means that MediaWiki 1.31 will no longer receive maintenance or
security backports. It is therefore strongly discouraged that you continue
to use it.
It is recommended to upgrade to MediaWiki 1.35, the current Long Term
Support (LTS) version which is not due to become EOL until September 2023.
MediaWiki 1.35 bumps the required PHP version from 7.0 in 1.31 (which is
unsupported upstream), to PHP 7.3.19 or later.
Thanks!
Sam Reed
[1] https://www.mediawiki.org/wiki/Version_lifecycle
Hi all,
Tomorrow we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
- 1.31.16
- 1.35.4
- 1.36.2
This will resolve 3 issues in MediaWiki core and also includes some fixes
previously committed to git, including minor security and hardening patches
along with bug fixes included for maintenance reasons.
It also fixes 1 issue in a MediaWiki tarball bundled extension.
We will make the fixes available in these respective release branches,
master and the currently unreleased 1.37 branch. 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.
As a reminder, 1.31 (the old LTS) was due to become end of life (EOL) in
June 2021. 1.35 (the new LTS) is supported until September 2023. However,
to try and meet our LTS-LTS overlap commitments (1.35 was late due to
COVID), 1.31 got best-efforts extra support until the end of September 2021.
As the end of September 2021 is now upon us, this means 1.31.16 will be the
final security (and maintenance) release, and therefore it is considered
EOL as of tomorrow, September 30, 2021.
[1] https://www.mediawiki.org/wiki/Version_lifecycle
Hi all,
The small group working to develop a peer exchange platform
<https://meta.wikimedia.org/wiki/The_Capacity_Exchange> for Wikimedians
needs some help with software development. We are looking for someone who
can do the installation and adaptation work of an existing java-based site
under a freelance contract. Details are described here
<https://wikimedia-deutschland.softgarden.io/job/12498172?l=de>:
If you or someone you know could do this work please contact us.
thanks!
Nikki
Nikki Zeuner
Senior Advisor Global Partnerships
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-32
Mobile (0151) 50824711
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
Bleiben Sie auf dem neuesten Stand! Aktuelle Nachrichten und spannende
Geschichten rund um Wikimedia, Wikipedia und Freies Wissen im Newsletter: Zur
Anmeldung <https://www.wikimedia.de/newsletter/>.
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.
Hey all,
A quick note that, after discussion on T288392[0], we've reconfigured
gitlab.wikimedia.org to use shell names for users instead of the LDAP
CN, and renamed all existing logins to match. This seems like a better
match for most users' expectations, and better ergonomics overall.
As a quick example, I was BrennenBearnes before, and now am at:
https://gitlab.wikimedia.org/brennen/
GitLab handles redirects for renamed users both in the web interface and
for git remotes, but if you want to reconfigure the remote URL for an
existing clone of a repo, you can do something like the following,
substituting your new username:
$ git remote set-url origin git@gitlab.wikimedia.org:brennen/test.git
[0]. https://phabricator.wikimedia.org/T288392
--
Brennen Bearnes
Release Engineering
Wikimedia Foundation
This is a summary of the 1.38.0-wmf.1 train deployment for the week of
2021-09-20.
Conductors: dduvall and hashar
Phabricator Task: <https://phabricator.wikimedia.org/T281165>
Deployment Status: Live on all wikis: <https://versions.toolforge.org/>
📊 Stats:
- 352 patches
- 3 risky patch notifications 🚂🔥
- 5 blockers (0 remain open)
- 0 rollbacks
📝 Notes:
The initial branch cut was for a 1.37.0 branch, and had to be re-run.
See: <https://phabricator.wikimedia.org/T281165#7367746>
Several user-facing regressions that could have been train blockers
didn't get surfaced to deployers, which has prompted some thinking about
the mechanisms by which the train actually gets blocked, and additional
places we could steer people to the train blocker task.
Thanks to everyone who helped see this train through to completion, in
particular (but in no particular order):
- Zabe
- DannyS712
- Legoktm
- matmarex
- Majavah
- kostajh
- James_F
As ever, we couldn't do it without you! 🚂🌈
TLDR: If you use "hard refresh" in your browser after editing a CSS or JS
page on the wiki, I'd like to hear about it so as to figure out whether
there may be a bug in the software. Please do test and confirm it for
yourself once more without a hard refresh, as it might just be an old habit
acting as a placebo :)
-
The "clearyourcache" message is the message that, contrary to its interface
key, instructs users to perform a page refresh in order to see the effect
of their edit to JS and CSS-related pages. For example:
https://translatewiki.net/wiki/MediaWiki:Clearyourcache/enhttps://en.wikipedia.org/wiki/MediaWiki:Common.csshttps://meta.wikimedia.org/wiki/MediaWiki:OSM.jshttps://meta.wikimedia.org/wiki/User:Krinkle/global.jshttps://en.wikipedia.org/wiki/MediaWiki:Citoid-template-type-map.json
As I understand it, this message is no longer be needed. I'm not aware of
any scenario in which a page carries this message, and edits to the page in
question would propagate to the editor's browser sooner as result of
performing a "hard reload".
If you find yourself doing hard reloads, or know people that do, I'd love
to hear detailed examples of specific combinations of pages/wikis/browsers
where people do this.
I've detailed the technical reasons for why these (should) have no impact,
on Phabricator:
https://phabricator.wikimedia.org/T291744
-- Timo
TLDR: I don't think the system messages for IRC are just for IRC. So I hope to change it.
Hi,
I am an extension developer and I am recently developing an extension[1] that provides a custom RCFeedEngine and an RCFeedFormatter. The purpose of the extension is to stream the recent changes in a wiki to a given Discord webhook.*
The RC feed engines send messages in a freely configurable format to an engine set in $wgRCEngines[2] and every RC log entry has a system message for RC feed output. For instance, logs for moving a page have a message named "1movedto2" which is represented "moved [[$1]] to [[$2]]" in English.
Disappointingly, I have found [[MediaWiki:1movedto2/qqq]] and similar messages on translatewiki include {{ignored}} template that says "This message is ignored on export for MediaWiki. Translating it is a waste of your effort!" and it seems to be true. The main cause of this is probably that the messages are only for irc.wikimedia.org and irc.wikimedia.org will be replaced with EventStreams? I couldn't find the exact reason.
In my opinion, the log entry messages are not just for IRC. IRC is an implementation of RCFeed and RCFeed is a general interface and can be extended in many ways as even the core includes multiple RCFeedEngines. So, if I'm not wrong, I'd like to create a ticket for enabling translation and request your opinions.
Regards.
-User:Lens0021
* There are a few extensions with a similar purpose. But the extensions are not RCFeedEngines and define their own system messages and use them instead of using the log entry messages.
---
[1] https://www.mediawiki.org/wiki/Extension:DiscordRCFeed
[2] https://www.mediawiki.org/wiki/Manual:$wgRCEngines
Hello everyone,
Wikimedia is participating in the winter edition of this year's Outreachy <
https://www.outreachy.org/> [1] (December 2021–February 2022)! The deadline
to submit projects on the Outreachy website is *September 30th, 2021*.
If you would like to share an idea for a project that you would like to
mentor or you are not familiar with the program and want to learn anything
more about it, feel free to reply to this email or leave a note on <
https://phabricator.wikimedia.org/T289893> [2].
*About the Outreachy program*:
Outreachy offers three-month internships to work remotely in Free and Open
Source Software (FOSS), coding and non-coding projects with experienced
mentors. These internships run twice a year–from May to August and December
to March. Interns are paid a stipend of USD 5,500 for the three months of
work. They also have a USD 500 stipend to travel to conferences and events.
Interns often find employment after their internship with Outreachy
sponsors or jobs that use the skills they learned during their internship.
This program is open to both students and non-students. Outreachy expressly
invites the following people to apply:
- Women (both cis and trans), trans men, and genderqueer people.
- Anyone who faces under-representation, systematic bias, or
discrimination in the technology industry in their country of residence.
- Residents and nationals of the United States of any gender who are
Black/African American, Hispanic/Latinx, Native American/American Indian,
Alaska Native, Native Hawaiian, or Pacific Islander.
See a blog post highlighting experiences and outcomes of interns who
participated in a previous round of Outreachy with Wikimedia <
https://techblog.wikimedia.org/2021/06/02/outreachy-round-21-experiences-an…>
[3]
Some tips for mentors for proposing projects:
- Follow this task description template when you propose a project in
Phabricator: <
https://phabricator.wikimedia.org/tag/outreach-programs-projects/> [4].
Add #Outreachy (Round 23) tag to it.
- Remember, the project should require an experienced developer ~15 days
to complete and a newcomer ~3 months.
- Each project should have at least two mentors, and one of them should
hold a technical background.
- When it comes to picking a project, you could propose one that is:
- Relevant for your language community or brings impact to the
Wikimedia ecosystem in the future.
- Welcoming and newcomer-friendly and has a moderate learning curve.
- A new idea you are passionate about, there are no deadlines
attached to it; you always wanted to see it happen but couldn't
due to lack
of resources help!
- About developing a standalone tool (possibly hosted on Wikimedia
Toolforge), with fewer dependencies on Wikimedia's core
infrastructure, it
doesn't necessarily require a specific programming language.
See roles and responsibilities of an Outreachy mentor <
https://www.mediawiki.org/wiki/Outreachy/Mentors> [5].
We look forward to your participation!
Cheers,
Srishti
(On behalf of the organization team)
[1] https://www.outreachy.org/
[2] https://phabricator.wikimedia.org/T289893
[3]
https://techblog.wikimedia.org/2021/06/02/outreachy-round-21-experiences-an…
[4] https://phabricator.wikimedia.org/tag/outreach-programs-projects/
[5] https://www.mediawiki.org/wiki/Outreachy/Mentors
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
I've just added a new status which can be applied to phabricator tasks.
It is now possible to explicitly mark a task as "In progress" to indicate
that you are working on it. This is in response to some Wikimedia teams
using a workflow that involves assigning tasks before work begins. Once
work begins in earnest, you can now make that status change explicit by
marking the task with the "In progress" status. Functionally it's
identical to "open," however, this will allow for some improvements to
progress tracking and reporting.
Feedback about this change can be submitted to Phabricator on the task[1]
[1] Evaluate adding "In progress" status to Phabricator.
<https://phabricator.wikimedia.org/T288956>