As usual with experimental standards that ship in the wild with "temporary"
semantics, the temporary semantics become defacto standard and the "future"
standard remains reserved for theoretical future use.
In T21165 <https://phabricator.wikimedia.org/T21165#6946526> I compare half
a dozen implementations and specs and observe that they all support
rel="alternate" whereas only one supports (in addition to rel="alternate")
also rel="edit".
Thus I'm concluding that rel="edit" is a dead standard and that at least
for right now there is no benefit to MediaWiki outputting it. There is a
cost for us to output it, but there is not really any signficant cost for
clients to support both, and supporting both is mandatory either way for
the theoretical future standard to be adopted.
If in another ten years notable clients actually supported the supposed
newer standard by then, we could switch at that time.
Task: https://phabricator.wikimedia.org/T21165
Commit: https://gerrit.wikimedia.org/r/722485
A potential argument could also be made that it should be removed entirely.
I myself have never understood why one would want a browser extension to
display an Edit button outside the viewport. It seems unappealing from a UX
perspective and for me personally would likely fade into
"banner blindness" and notice if it were detected and/or notice it too much
if it tries to get my attention on any editable page. In any event, while I
would love to hear from people who find this useful, I am /not/ proposing
its removal.
-- Timo
TLDR:
The way key-values passed to $logger->debug() and $logger->warning() are
shown in Logstash will soon change. The proposed transition will be
forward- and backward- compatible for at least 90 days, so you can always
find your logs in one place, and will not need to update any queries (yet).
Today, metadata from Syslog, Monolog processors, and MediaWiki context
arrays are mixed into one flat array. After the transition, rows in
Logstash will preserve the context as its own array under a "context" key.
Visual example at https://phabricator.wikimedia.org/T247675#7360872.
Background
Our wiring code for Logstash has diverged from upstream. The V0 format,
which we have effectively forked, has various usability issues.
For these two reasons, the few of us looking after the debug/monolog code
(incl Reedy, Daimona, and myself) would like to transition to use
upstream's V2 format directly without some of the overrides we currently
have.
If you use Logstash regularly and are worried this might affect your
workflow, check out the transition plan [1] and comment on Phabricator (or
email me) with any suggestions or concerns that I might have missed.
[1] https://phabricator.wikimedia.org/T247675#7360872
-- Timo
Another week, another train.
Your train conductors: mmodell and hashar
Phabricator Task: T281164 <https://phabricator.wikimedia.org/T281164>
Deployment Status: Live on all wikis <https://versions.toolforge.org/>
Notable things about this train:
- Train happened during DC switchover week (codfw -> eqiad).
- Italian wikipedia moved from group2 to group1, bringing the number of
group1 wikis to 3. Thanks Jon Robson
- 3 risky change notifications. Thank you!
Many thanks to the following people who participated in this week's train.
We can't do it without you!
daniel
DannyS712
Zabe
Legoktm
Majavah
Joe
James F
Umherirrender
Etonkovidova
matmarex
Krinkle
Jdlrobson
AntiCompositeNumber
Daimona
urbanecm
Tgr
Mholloway
Mike's suggestion is good. You would likely get better responses by asking
this question to the Wikimedia developers, so I am forwarding to that list.
Risker
On Thu, 16 Sept 2021 at 14:04, Gava, Cristina via Wikimedia-l <
wikimedia-l(a)lists.wikimedia.org> wrote:
> Hello everyone,
>
>
>
> It is my first time interacting in this mailing list, so I will be happy
> to receive further feedbacks on how to better interact with the community :)
>
>
>
> I am trying to access Wikipedia meta data in a streaming and time/resource
> sustainable manner. By meta data I mean many of the voices that can be
> found in the statistics of a wiki article, such as edits, editors list,
> page views etc.
>
> I would like to do such for an online classifier type of structure:
> retrieve the data from a big number of wiki pages every tot time and use it
> as input for predictions.
>
>
>
> I tried to use the Wiki API, however it is time and resource expensive,
> both for me and Wikipedia.
>
>
>
> My preferred choice now would be to query the specific tables in the
> Wikipedia database, in the same way this is done through the Quarry tool.
> The problem with Quarry is that I would like to build a standalone script,
> without having to depend on a user interface like Quarry. Do you think that
> this is possible? I am still fairly new to all of this and I don’t know
> exactly which is the best direction.
>
> I saw [1] <https://meta.wikimedia.org/wiki/Research:Data> that I could
> access wiki replicas both through Toolforge and PAWS, however I didn’t
> understand which one would serve me better, could I ask you for some
> feedback?
>
>
>
> Also, as far as I understood [2]
> <https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake>, directly
> accessing the DB through Hive is too technical for what I need, right?
> Especially because it seems that I would need an account with production
> shell access and I honestly don’t think that I would be granted access to
> it. Also, I am not interested in accessing sensible and private data.
>
>
>
> Last resource is parsing analytics dumps, however this seems less organic
> in the way of retrieving and polishing the data. As also, it would be
> strongly decentralised and physical-machine dependent, unless I upload the
> polished data online every time.
>
>
>
> Sorry for this long message, but I thought it was better to give you a
> clearer picture (hoping this is clear enough). If you could give me even
> some hint it would be highly appreciated.
>
>
>
> Best,
>
> Cristina
>
>
>
> [1] https://meta.wikimedia.org/wiki/Research:Data
>
> [2] https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake
> _______________________________________________
> Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
> To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
During today's train deployment for 1.37.0-wmf.23, we discovered a couple
of blocking issues which resulted in rolling back to group 0.
Here they are in all of their glory:
1. T291128 Wikimedia\Rdbms\DBQueryError: Error 1146: Table
'arbcom_dewiki.echo_push_subscription' doesn't exist
<https://phabricator.wikimedia.org/T291128>
2. T291124 PHP Notice: Undefined index: format
<https://phabricator.wikimedia.org/T291124>
The first issue is puzzling. The error was noticed during roll forward but
the stack indicates that it's version wmf.21. Furthermore, as pointed out
by subbu, the table should have been created back in 2020:
subbu>
> https://github.com/wikimedia/mediawiki-extensions-Echo/blob/master/db_patch…
> ... 2020.
>
There is ongoing discussion in IRC around this so perhaps it's fixed by the
time you read this.
The second issue appears to be related to compatibility of serialized
objects across versions. See the task for some commentary by Daimona.
If you've got any ideas, we'd love to hear your thoughts. Patches are also
welcome.:)
<3
- Your humble train (co-)conductor.
Hey all,
This is a quick note to highlight that in three weeks' time, the REL1_37
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.37, which should be out in late November 2021, approximately
six months after MediaWiki 1.36.
The branches will reflect the code as of the last 'alpha' branch for the
release, 1.37.0-wmf.23, which will be deployed to Wikimedia wikis in the
week beginning 13 September 2021 for MediaWiki itself and those extensions
and skins available there. (Note that there will not be a 1.37.0-wmf.22
deployment, so there are only two Wikimedia production train deployments
inclusive between now and the branch point.)
After that point, patches that land in the main development branch of
MediaWiki and its bundled extensions and skins will be slated for the
MediaWiki 1.38 release unless specifically backported[1].
If you are working on a new feature that you wish to land for the release,
you now have three weeks 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.37-release` project
on Phabricator.[2]
If you have tickets that are already tagged for `mw-1.37-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.37.0-rc.0, two weeks after
the branch point, and if all goes well, to release MediaWiki 1.37.0 a few
weeks after that.
[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.37-release/>
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
Hello,
This email is to inform you of a small backwards-incompatible change to LinksUpdate class in MediaWiki core.
LinksUpdate::getTriggeringUser method will start returning an instance of UserIdentity instead of a User object
as of [1]. All 2 known usages of this method are satisfied with UserIdentity interface, and going through a full
deprecation process here would require renaming the method and will just cause more pain to extension
developers.
Best regards.
Petr Pchelko
Staff Software Engineer
Platform Engineering at WMF
1.https://gerrit.wikimedia.org/r/c/mediawiki/core/+/698820 <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/698820>
Hello everyone,
We are planning to rework ILocalizedException, which will break anything
implementing the interface. Ticket: T287405
<https://phabricator.wikimedia.org/T287405>
TL;DR: The change will deprecate ILocalizedException::getMessageObject()
and replace it with ::getMessageValue()
Of course, we will take care of updating affected Wikimedia deployed
extensions.
Please refer to the ticket and comment if you have any questions or
concerns.
Best,
--
*Thomas Chin <https://meta.wikimedia.org/wiki/User:TChin_(WMF)>* (he/him)
Software Engineer - Platform Engineering
Wikimedia Foundation <https://wikimediafoundation.org/>