I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here.
tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.)
(Is there a place on mw.org to put this tidbit on?)
------- Forwarded message -------
From: "Brian Levine" <support(a)github.com> (GitHub Staff)
To: matma.rex(a)gmail.com
Cc:
Subject: Re: Commits in mirrored repositories not showing up on my profile
Date: Tue, 09 Jul 2013 06:47:19 +0200
Hi Bartosz
In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit.
The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits.
Cheers
Brian
--
Matma Rex
We just released a new version of Research:FAQ on Meta [1], significantly
expanded and updated, to make our processes at WMF more transparent and to
meet an explicit FDC request to clarify the role and responsibilities of
individual teams involved in research across the organization.
The previous version – written from the perspective of the (now inactive)
Research:Committee, and mostly obsolete since the release of WMF's open
access policy [2] – can still be found here [3].
Comments and bold edits to the new version of the document are welcome. For
any question or concern, you can drop me a line or ping my username on-wiki.
Thanks,
Dario
[1] https://meta.wikimedia.org/wiki/Research:FAQ
[2] https://wikimediafoundation.org/wiki/Open_access_policy
[3] https://meta.wikimedia.org/w/index.php?title=Research:FAQ&oldid=15176953
*Dario Taraborelli *Head of Research, Wikimedia Foundation
wikimediafoundation.org • nitens.org • @readermeter
<http://twitter.com/readermeter>
TLDR: Invoking maintenance scripts directly will be deprecated in MW 1.40, use
maintenance/run.php instead. This affects anyone managing a MediaWiki
installation, for development, testing, or production use.
Until now, MediaWiki maintenance scripts have been handled standalonePHP scripts
- for instance, to run the script that outputs the MediaWiki version, you would use:
> php maintenance/version.php
Starting with MediaWiki 1.40, this is deprecated. The preferred way to run
maintenance scripts is now by name, using the maintenance runner:
> php maintenance/run.php version
Similarly, the preferred way to run the updater is now:
> php maintenance/run.php update
The script to run cal also be specified using the full path of the script file,
or the full PHP class name of a subclass of the Maintenance class. For more
details, run
> php maintenance/run.php --help
Rationale and History:
Treating maintenance scripts as standalone PHP scripts requires some boilerplate
code to be present at the top and at the bottom of every file. This is error
prone and makes it difficult to update the maintenance framework. But more
importantly,
for this boilerplate to work, the location of the MediaWiki installation has to
be known relative to the maintenance script, which is not reliably possible for
scripts defined in extensions.
A similar problem arises if the maintenance script needs a base class other than
the default Maintenance class: since the class is loaded before MediaWiki is
initialized, the autoloader is not yet in place, and the file containing the
base class needs to be included explicitly.
These and similar issues can be avoided by creating a wrapper script that loads
and executes the actual maintenance class. This way, the maintenance wrapper can
initialize MediaWiki before passing control to the script.
I propose creating such a wrapper as an RFC in 2018 (T99268)[^1], which was
approved in 2019. However, implementing the proposal proved challenging, and
soon stalled. I picked it up again as a side project after working on
overhauling the configuration and bootstrapping code in early 2022: With the
introduction of SettingsBuilder, it became much simpler to create a
MaintenanceRunner class, because it was no longer necessary to juggle global
variables.
Several bits and pieces got reviewed and merged over the course of 2022 (shout
out to Amir, Tim, Timo, and everyone who contributed). Now the runner is ready,
and we should stop calling maintenance scripts directly.
For now, existing maintenance scripts will function both ways[^2] : when called
using the runner, or directly. However, newly created maintenance scripts should
not be required to be callable as standalone scripts. So it's best to change all
callers to use the wrapper.
This should now work for nearly all[^2] cases, though there are still a couple
of rough edges to be smoothed out. If you are running MediaWiki 1.40, please try
the new mechanism, and report any isses on Phabricator.
Thanks,
Daniel
[^1] https://phabricator.wikimedia.org/T99268
[^2] with the exception over very old-school scripts that do not use the
Maintenance base class and rely on CommandLineInc.php instead.
--
Daniel Kinzler
Principal Software Engineer, Platform Engineering
Wikimedia Foundation
Hi,
On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote:
> We will be holding this brownbag in 25 minutes. The Bluejeans link has
> changed:
>
> https://bluejeans.com/396234560
I'm not familiar with bluejeans and maybe have missed a transition
because I wasn't paying enough attention. is this some kind of
experiment? have all meetings transitioned to this service?
anyway, my immediate question at the moment is how do you join without
sharing your microphone and camera?
am I correct thinking that this is an entirely proprietary stack
that's neither gratis nor libre and has no on-premise (not cloud)
hosting option? are we paying for this?
-Jeremy
The Tech Department at Wikimedia Foundation [1] invites you to a* special
event on February 09, 2023, at 1600 UTC* [2].
*Richard Evans, Electronics & Data Systems Engineer At NASA Glenn Research
Center *[3], will be presenting on *how MediaWiki is being used within NASA*
to help manage the testing of very large spacecraft to prove they can
survive the harsh conditions of launch, orbit, and re-entry. The management
platform is built from MediaWiki and several key extensions that provide
workflow support. This evolving platform plans to incorporate the
extensions that form the MediaWiki-powered Open CSP platform [4]. This talk
will explain the architecture and benefits of the NASA platform and
motivate the need for Open CSP. We’ll also be recording the event to share
with those who can’t make it. You can join the event through Google Meet
[5].
Looking forward to seeing you there,
*--on behalf of the Tech Department, Wikimedia Foundation.*
*(For follow-ups, please reach out to *lnguyen(a)wikimedia.org.)
[1] https://www.mediawiki.org/wiki/Wikimedia_Technology
[2] https://zonestamp.toolforge.org/1675958415
[3] https://www.wikidata.org/wiki/Q618728#sitelinks-wikipedia
[4] https://www.open-csp.org/Main_Page
[5]
https://stream.meet.google.com/stream/ce81307c-cdb7-4a5e-9697-65c423f27614
--
________________________________
Erica Litrenta (she/her)
Senior Manager, Community Relations Specialists (Product)
Wikimedia Foundation
TLDR: Any ResourceLoader module will now run on mobile or desktop site by
default. Previously they would only load on the desktop site.
Hopefully this goes without disruption, but to be safe, if you maintain
code used in Wikimedia production, please:
1) check your experiences over the course of this week in mobile/desktop
site for JS errors/obvious UI errors (the former will be detected and
monitored via logstash)
2) check that your repository doesn't fail the core
testUnsatisfiableDependencies PHPUnit test. 3) Please check out the
following Phabricator tickets to see if you are impacted on the long term
[4][5].
# Background
Back in the early days of MobileFrontend, most of the JavaScript we had was
not mobile friendly. To avoid this we created an allow-list system, where
JavaScript was disabled by default and extensions/skins had to explicitly
enable it by adding a "targets" property to their ResourceLoaderModule
definition.
This was meant as a short term solution, but as with many things, attention
got pulled elsewhere, and almost ten years later it was still there.
There have been many complaints about this over those years. Mainly:
1) It means we have split the ResourceLoader cache further
2) It's not intuitive - new code was getting shipped to desktop only
experiences by default.
It also featured on the Developer Wishlist of 2017 at #34 [1].
3) Many older features don't work for community members for no credible
reason.
# Recent developments
As one of the few remaining people responsible for doing this in the first
time, I felt obliged to spend some time over December trying to pay off
this technical debt. I audited code that was being removed by the targets
system [2] and made the target explicit. Where modules were problematic on
mobile, we marked them in such a way that it was clear that they should
only run in a certain mode. This was only possible thanks to attention from
Amir, Santosh, Thiemo, Lucas W, Tpt, Sohom D, Bartosz - thank you all.
Today, Roan merged a change that makes ResourceLoader modules default to
the desktop AND mobile sites. This should be a harmless change, but may be
unintentionally triggering failures in testUnsatisfiableDependencies tests
as it seems some extension/skins are not included in the MediaWiki core
PHPUnit test run. If you encounter this issue, the fix is relatively simple
- you must define targets explicitly (see this example [6] and apologies in
advance for any annoyance this may cause)
# For action
Please take extra care with your code that you test on both mobile/desktop
sites and at mobile/desktop breakpoints. It's still possible to ship code
to mobile/desktop and see these guidelines [3] if you need to do that or
reply to this email with any questions you have.
# Next steps
This change will help with limiting the targets system to existing known
cases. This has been a long term request of the performance team. Please
see the follow up tickets to see if there is any action from you at your
leisure [4][5].
[1] https://www.mediawiki.org/wiki/Developer_Wishlist/2017/results
[2] in https://phabricator.wikimedia.org/T324723
[3]
https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension…
[4] https://phabricator.wikimedia.org/T328497
[5] https://phabricator.wikimedia.org/T328498
[6]
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PropertySuggester/+/8…
Hello all!
The Search Platform Team usually holds an open meeting on the first
Wednesday of each month. Come talk to us about anything related to
Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query
Service (WCQS), etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, February 1st, 2023
Time: 16:00-17:00 UTC / 08:00 PDT / 11:00 EDT / 17:00 CET
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vgj-bbeb-uyi
Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927
Have fun and see you soon!
Guillaume
--
*Guillaume Lederrey* (he/him)
Engineering Manager
Wikimedia Foundation <https://wikimediafoundation.org/>