If you're not interested in Selenium tests, you can ignore this message.
I'm working on improving our Selenium framework. That means I'm creating a
few patches a week. I'm looking for reviewers. Please reply off-list if you
would like to be a reviewer on a Selenium related patch.
You can see the type of patches I'm creating in Gerrit.
I would like to thank my usual reviewers, James Forrester and Timo Tijhof
for reviewing many many commits so far.
(If you don't locally run PHPUnit tests on MediaWiki, you can skip this
In order to simplify our PHPUnit configuration, the following CLI
options for tests/phpunit/phpunit.php were replaced by environment
variables in a patch that just landed in the HEAD branch:
* --wiki=foo => PHPUNIT_WIKI=foo
* --use-normal-tables => PHPUNIT_USE_NORMAL_TABLES=1
* --reuse-db => PHPUNIT_REUSE_DB=1
* --use-filebackend=foo => PHPUNIT_USE_FILEBACKEND=foo
* --use-bagostuff=foo => PHPUNIT_USE_BAGOSTUFF=foo
* --use-jobqueue=foo => PHPUNIT_USE_JOBQUEUE=foo
Furthermore, some of these options are being considered for removal, so if
you regularly use them, please raise your voice on the task.
Thank you, and thanks to James F, Kosta and Timo for your help with moving
 - See https://phabricator.wikimedia.org/T90875 for details
"Daimona" is not my real name -- he/him
I wanted to send a heads-up to various places that MediaWiki 1.31, the
legacy LTS release, will be End-of-Life as of next month, June 2021.
There will be a final release to follow-on from the current latest version
1.31.14 coming out in June, but it may have slipped people's mind that this
deadline is approaching so swiftly.
System administrators still using 1.31 are encouraged to start their
migration to the current LTS release, 1.35. MediaWiki 1.35, released in
September 2020, will be supported until September 2023. If you don't
require LTS support, you will be able to upgrade to 1.36 which will be
supported till May 2022 once it is released, before the end of the month.
As always, please be mindful of the upgrade instructions, especially
including making a back-up of your database, and testing extension
tl;dr: We're still moving to GitLab. WMF Release Engineering & SRE are
working with contractors on an MVP installation of GitLab CE, which we
hope to have running by July, and in use by early-adopter projects soon
thereafter. Read on for more details.
It's been over six months since we wrapped up the GitLab consultation
process with a decision to migrate from Gerrit to GitLab's Community
Edition. It seemed like a good idea to update the community with our
progress since then.
We currently have contractors from Speed & Function working on a
minimum-viable installation of GitLab CE. We hope to be fairly
confident installing this by the end of June (end Q4 of WMF's fiscal
year). You can follow this work on the "GitLab (Initialization)"
workboard in Phabricator.
Additionally, we're hiring for two Service Operations SRE positions to
build and support a more robust production installation, and planning
for new job runner capacity to handle CI on GitLab.
Tentatively, we in RelEng hope to begin using GitLab for some of our own
projects around July (early Q1 of WMF fiscal year) and begin migrating
other projects thereafter. (Keeping in mind, of course, that everything
takes longer than you expect.)
We've already heard from some people that their project or team is
interested in being an early adopter of GitLab. If that describes you,
please add a comment on T282842:
Feel free to reach out with any questions!
Under the tag of WP:BOLD I took the liberty of copying the "Page security extension disclaimer" that is put on extension pages whenever an extension uses a legit hook like "usercan" .
While I get why the disclaimer is added, the words used in the disclaimer are certainly up for improvements.
It now states, whenever you need security, use another package, not MediaWiki. It also brands an extension using legit hooks to be a hack.
So I made a simple template "Page security extension disclaimer 2021" that still shares the sames bottomline message : "MediaWiki is not responsible for exposed content", but using words that are more appropriate.
I would like people to review the original disclaimer and the text I have used to come up with a suitable solution.