The 1.37.0-wmf.12[0] train is currently blocked at group1 by an UBN bug:
T287704 [1].
The culprit seems to be [2] which added strict type checking to some
methods that are being called in a disagreeable manner from LUA code. For
the short time that wmf.16 was deployed to all wikis, errors were occurring
on at least svwiki and yuewiki at a rate of 900+ fatals per minute.
A clean revert of the offending patch isn't possible because other code
built on top of it. For now at least it would appear that the train is
blocked. Any assistance with resolving the issue is appreciated as always.
To keep up with the most current status please watch the train blocker
task[3] in Phabricator.
---
- 💕- Your humble train conductor.
1. https://phabricator.wikimedia.org/T287704
2. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/704998
3. https://train-blockers.toolforge.org/
Hi all,
This email is of interest to you only if you're a user of the "Wikimedia
Debug" browser extension. If you're not, you can safely skip it.
As the more attentive might have noticed, the Wikimedia Debug browser
extension started offering a new option in the drop-down menu, besides the
usual mwdebug servers, labeled "k8s-experimental". That is, as the name
suggests, a very experimental setup of mediawiki running on kubernetes and
is not *yet* a place where you will be able to test your releases.
Right now, that installation is a work in progress, but nonetheless it
seemed important to us to have a way to browse the wikis from the
installation running on kubernetes while we iron out bugs in preparation
for the actual migration of production traffic.
This installation can thus:
- run on outdated versions of mediawiki (although we're trying to follow
train releases).
- be down for extended periods of time while we debug something, without
warning.
It also doesn't support (yet) profiling via xhprof.
So while we welcome the curious to poke around at the performance and bugs
of the installation, it is not a suitable tool (yet) to debug your releases
on.
I will add filters where appropriate to avoid logs from this installation
from polluting your dashboards in the coming days, but in the meantime, if
you see a log line coming from a server with a strange name like
"mediawiki-pinkunicorn"... that's mediawiki running on kubernetes and you
can mostly ignore it!
You can follow our progress at https://phabricator.wikimedia.org/T283056
Cheers,
Giuseppe
--
Giuseppe Lavagetto
Principal Site Reliability Engineer, Wikimedia Foundation
This is a belated summary of *last week*'s deployment of the 1.37.0-wmf.15
branch of MediaWiki, extensions, and skins (also known as "the train").
The primary person in charge last week was Antoine (hashar) Musso, with
Ahmon Dancy as backup, both from the Wikimedia Foundation Release
Engineering team.
The summary/blocker task for this week is:
https://phabricator.wikimedia.org/T281156
The new version is running on all sites: https://versions.toolforge.org/
== 📈 Stats ==
* 229 patches (15th smallest train since 1.31)
* 0 risky patches
* 0 time spent rolled back
* 1 day of delay
* 2 blockers were added, 0 were resolved, 2 blockers were removed
== 🚂🌈==
Everyone who deployed, triaged, and had code riding the train this week:
thank you. We've deployed another trainbow*!
Thanks especially to the folks who added and removed blockers this week:
* Timo Tijhof
* Daniel Kinzler
* Brennen Bearnes
❤️🔥
– Train Troop
* trainbow – a neologism meaning "happy and successful train" — a
portmanteau of "train" and "rainbow"!
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2021.07. This bundle is compatible with MediaWiki 1.35 or above
and requires PHP 7.2 or above.
Next MLEB is expected to be released in 3 months. If there are very
important bug fixes, we will do an intermediate release. Please give
us your feedback at
[[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2021.07.tar…
* sha256sum: f7cd8113c095375be51464429dff04c8fa5bb88bc22ba3d780bf5698668e52c5
* Signature: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2021.07.tar…
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://phabricator.wikimedia.org/project/view/1464/
Release notes for each extension are below.
-- Kartik Mistry
== Babel, cldr, CleanChanges and LocalisationUpdate ==
* Localisation and maintenance updates.
== Translate ==
* '''BREAKING CHANGE''': Translate extension now requires MediaWiki
1.35 or above.
* When translating in Page mode, modifying and publishing a message
causes its to become empty ({{phab|T270819}})
* '''SECURITY''': Enhance validation and logging for AggregateGroups
API deletions ({{phab|T282932}})
* Make Special:PageTranslation work with ONLY_FULL_GROUP_BY ({{gerrit|701871}})
* '''BREAKING CHANGE''': Remove TranslateMessageGroupPathVariables
hook ({{gerrit|701678}})
* GettextFFS: Only allow pot mode for source language ({{phab|T230361}})
* Translation page deletion should not clear metadata ({{gerrit|694306}})
* Added content model and handler for translatable modules
({{gerrit|638528}}, {{phab|T271406}})
* Allow showing yearly stats in Special:TranslationStats ({{phab|T281244}})
* '''BREAKING CHANGE''': Remove Validator and LegacyValidatorAdapter
({{gerrit|685438}})
* Improve display of very long insertables ({{gerrit|685805}})
* Fix "Translation units to be deleted appear with unit ID -1 on
Special:PageTranslation" ({{phab|T283971}})
* Localisation updates.
=== Configuration variable changes ===
To address voice and tone issues in the Translate extension
({{phab|T277965}}) the following configuration variable names have
been renamed:
* <code>TranslateBlacklist</code> →
<code>TranslateDisabledTargetLanguages</code>
* <code>TranslateAuthorBlacklist</code> →
<code>TranslateAuthorExclusionList</code>
* <code>TranslateCheckBlacklist</code> →
<code>TranslateValidationExclusionFile</code>
''The old variables will be supported for MLEB 2021.07 release but
removed in the MLEB 2021.10 release.''
If you have defined
[[Help:Extension:Translate/Group_configuration|message groups]]
defined with <code>LANGUAGE</code> attributes,
<code>whitelist/blacklist</code> have been changed to
<code>include/exclude</code>
== UniversalLanguageSelector ==
* '''BREAKING CHANGE''': UniversalLanguageSelector extension now
requires MediaWiki 1.35 or above.
* MODERN VECTOR: Position language menu below language button ({{phab|T276248}})
* Update jquery.uls and jquery.ime from upstream
* Fix "Suggested language list not available for ULS version in new
language button". ({{phab|T282037}})
* MODERN VECTOR: Fix "ULS settings window can’t be opened with the
preferences link on new Vector". ({{phab|T282956}})
* Fix "ULS preferences tool link cannot be opened when compact
languages disabled" ({{phab|T286574}})
* Localisation updates.
--
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com
Hi,
As part of the Libera Chat migration, myself and some others worked on
developing "ircservserv"[0], which allows you to mostly manage IRC
channel ACLs and settings using Git. Basically think GitOps, but for IRC.
Instead of having to look up the various ChanServ and /mode commands
each time, you make your change in a human readable TOML file, have CI
validate it, and then deploy it. It also takes care of all the boring
channel set up options like enabling global bans, giving permissions to
Libera staff, etc.
Once initially set up, it's mostly self-service in that you can change
your channel's configuration without needing intervention from the
ircservserv maintainers.
The full documentation and examples are available at
<https://meta.wikimedia.org/wiki/IRC/Bots/ircservserv>. If there's some
functionality you'd like/need and it's missing, please file a bug in
Phabricator.
Note that for now this should only be used for public channels. [1]
tracks deploying an instance in production for private channels.
Big thanks to Majavah for co-maintaining it with me and Skizzerz for
answering all my questions about the IRC/ChanServ protocols.
[0] what you end up with when you pick a name at 3am.
[1] https://phabricator.wikimedia.org/T283492
-- Kunal
Apologies for cross-posting. The full release description including
further statistics can be found on
https://www.dbpedia.org/blog/snapshot-2021-06-release/
<https://www.dbpedia.org/blog/snapshot-2021-06-release/>.
We are pleased to announce immediate availability of a new edition of
the free and publicly accessible SPARQL Query Service Endpoint and
Linked Data Pages, for interacting with the new Snapshot Dataset.
What is the “DBpedia Snapshot” Release?
Historically, this release has been associated with many names: "DBpedia
Core", "EN DBpedia", and — most confusingly — just "DBpedia". In fact,
it is a combination of —
*
EN Wikipedia data— A small, but very useful, subset (~ 1 Billion
triples or 14%) of the whole DBpedia extraction
<https://link.springer.com/chapter/10.1007/978-3-030-59833-4_1>using
theDBpedia Information Extraction Framework
<https://github.com/dbpedia/extraction-framework>(DIEF), comprising
structured information extracted from the English Wikipedia plus
some enrichments from other Wikipedia language editions, notably
multilingual abstracts in ar, ca, cs, de, el, eo, es, eu, fr, ga,
id, it, ja, ko, nl, pl, pt, sv, uk, ru, zh.
*
Links— 62 million community-contributed cross-references and
owl:sameAs links to other linked data sets on the Linked Open Data
(LOD) Cloud that allow to effectively find and retrieve further
information from the largest, decentral, change-sensitive knowledge
graph on earth that has formed around DBpedia since 2007.
*
Community extensions— Community-contributed extensions such as
additional ontologies and taxonomies.
Release Frequency & Schedule
Going forward, releases will be scheduled for the 15th of February, May,
July, and October (with +/- 5 days tolerance), and are named using the
same date convention as the Wikipedia Dumps that served as the basis for
the release. An example of the release timeline is shown below:
June 6–8
June 8–20
June 20–July 10
July 10–20
Wikipedia dumps for June 1 become available on https://dumps.wikimedia.org/
Download and extraction with DIEF
Post-processing and quality-control period
Linked Data and SPARQL endpoint deployment
Data Freshness
Given the timeline above, the EN Wikipediadata of DBpedia Snapshot has a
lag of 1-4 months.
Further Information
Growth of DBpedia, breakdown of links by domain, download instructions
and some tips on how to effectively work with DBpedia are published as
part of this blog post:
https://www.dbpedia.org/blog/snapshot-2021-06-release/
<https://www.dbpedia.org/blog/snapshot-2021-06-release/>
Hello.
TLDR: In MW core, RELEASE-NOTES is a cause of the majority of merge conflicts.
I propose to restructure it in a way that could let us do less manual conflict resolutions in Gerrit.
The problem
When working on MediaWiki core, all of us often need to update RELEASE-NOTES-XX file
in case some deprecations or breaking changes were made. While the change is under review,
other changes touching RELEASE-NOTES-XX are made, causing merge conflicts that need
to be resolved manually. Non insignificant portion of manual conflict resolutions are needed
exclusively due to RELEASE-NOTES.
This is not a surprise due to the structure of the notes file. It has several sections, with every
section being a list of individual notes. Since most of us only append lines to the end of the list,
it creates a contention.
The proposal
I propose to reorganize RELEASE-NOTES. We keep the sections, but within each section
we start the note with the name of the class that’s been touched, if it makes sense.
For example, instead of writing
* In AbstractBlock, the getTargetAndType() and getTarget() methods are
hard deprecated. Instead use getTargetName() and getTargetUserIdentity()
together with getType().
We would write
* AbstractBlock: the following method were hard-deprecated:
- getTarget() - use getTargetName() or getTargetUserIdentity()
- getTargetAndType() - use getType() with getTargetUserIdentity() or getTargetName()
After switching to a more standardized format, we sort individual notes alphabetically by class
name. Method names within messages need to be sorted alphabetically as well. This will make
an insertion point of new release notes more random, hopefully reducing the contention and
thus reducing the probability of a merge conflict. Additionally, I personally think this will look nicer
and will be easier to read for extension developers.
Not all the release notes can follow this pattern, and it’s ok. The point is not to be perfect, the
point is to try to be better.
Alternative solutions
We could write a custom merge driver for RELEASE-NOTES which always puts ‘ours’ before ’theirs’,
but I’m not sure the result will justify the investment.
Feedback
Please tell me what you think about this.
- Do you think it is a real problem?
- Do you think simply restructuring the notes with help?
- Do you think writing a custom merge driver is a way to go?
- Will you remember to follow the new structure if we agree on it even though it’s not really possible
to enforce with linters since not all the notes can follow this structure?
- Extension developers - do you care? Do you think alphabetically sorted RELEASE-NOTES will be
any easier for you to read?
Thank you.
Petr Pchelko.
Staff Software Engineer.
WMF Platform Engineering Team.
Hi all,
we propose to remove `capitalize-all-nouns` skin functionality from
MediaWiki core without deprecation in 1.37.
Patch to remove: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/435638
Patch to continue functionality in Monobook:
Bug: https://phabricator.wikimedia.org/T97892
Existing uses:
https://codesearch.wmflabs.org/search/?q=MagicWord%3A%3AclearCache&i=nope&f…
MediaWiki core has a feature whereby the setting $capitalizeAllNouns = true
can be set in a LanguageXx.php file. When this is set, OutputPage attaches
the `capitalize-all-nouns` CSS class to the page <body> element. The only
languages for which $capitalizeAllNouns = true are German and languages
with German as a fallback (e.g. Alemannic).
The only widely used skin using this has been Monobook to disable lowercase
transformation of tab titles for those languages. A few other skins might
have applied the same functionality when basing on top of Monobook.
We've copied this obscure functionality over to Monobook in the meantime
and would recommend doing so for your skin if you like to continue to use
it.
In any case, as this removal results in a non-existing CSS class mostly
rendering of some elements of the skin in some languages would change
slightly.
Please note, that no other modern Wikimedia deployed skin has used this
ever since Monobook.
Thanks to volunteer Jack Phoenix and my colleague Jon Robson for driving
this work.
Regards,
Volker
Hello,
I have released Quibble 1.0.0 a few minutes ago.
I wrote the first line of code during the 2017 Wikimania Hackathon
(Vienna, Austria). It has since served hundred of thousands of builds on
our CI and Kosta Harlan rightfully pointed out it was about time to
endorse as being stable. Hence 1.0.0.
A quick summary:
* Use glob pattern in composer.local.json
* Support for mediawiki/core composer run phpunit:entrypoint which will
eventually replace our old phpunit.php wrapper.
* Can now connect to an existing MySQL database (--db-is-external)
* Load Parsoid from vendor as a fallback
The changelog with a few more details is at:
https://doc.wikimedia.org/quibble/changelog.html
cheers,
--
Antoine "hashar" Musso