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>
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
As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA
instead of DB_SLAVE, with the old constant left as an alias. This is part
of a string of commits that cleaned up the mixed use of "replica" and
"slave" by sticking to the former. Extensions have not been mass
converted. Please use the new constant in any new code.
The word "replica" is a bit more indicative of a broader range of DB
setups*, is used by a range of large companies**, and is more neutral in
connotations.
Drupal and Django made similar updates (even replacing the word "master"):
* https://www.drupal.org/node/2275877
* https://github.com/django/django/pull/2692/files &
https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a023…
I don't plan on doing anything to DB_MASTER, since it seems fine by itself,
like "master copy", "master tape" or "master key". This is analogous to a
master RDBMs database. Even multi-master RDBMs systems tend to have a
stronger consistency than classic RDBMs slave servers, and present
themselves as one logical "master" or "authoritative" copy. Even in it's
personified form, a "master" database can readily be thought of as
analogous to "controller", "governer", "ruler", lead "officer", or such.**
* clusters using two-phase commit, galera using certification-based
replication, multi-master circular replication, ect...
**
https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_…
***
http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium…
--
-Aaron
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
I (with Reedy's help) recently started work on librarizing MediaWiki's
IP class into a separate composer package (wikimedia/ip-utils[1]). The
main motivation was so that the Parsoid PHP port could use it[2].
However, I ran into an unexpected hitch[3], as it seems we're using
the IP class before the composer autoloader is even intialized. Here's
the basic initialization in Setup.php:
- - AutoLoader.php (MediaWiki's)
- - Defines.php
- - DefaultSettings.php
- $wgServer = WebRequest::detectServer()
- Calls IP::splitHostAndPort()
- - GlobalFunctions.php
- - vendor/autoload.php (composer's)
My understanding is that composer's autoloader runs late so extensions
registering themselves using it can add their stuff to the necessary
globals.
And we call WebRequest::detectServer() in DefaultSettings.php so that
in LocalSettings.php people can use the value of $wgServer for other
stuff.
I see 3 main ways to move forward:
1. Move vendor/autoload.php earlier in Setup.php, potentially breaking
extensions that still rely on composer autoloading for initialization.
2. Set $wgServer = false or something in DefaultSettings.php, and then
fill it in later in Setup.php *after* the composer autoloader has been
loaded, potentially breaking anyone relying on the value of $wgServer
in LocalSettings.php.
3. (status quo) not librarize code that runs before composer
autoloader initialization. :(
Advice/input welcome.
[1] https://packagist.org/packages/wikimedia/ip-utils
[2]
https://gerrit.wikimedia.org/g/mediawiki/services/parsoid/+/77064cfff717
6493a2828bb4f95f397dfce7d659/src/Utils/Title.php#46
[3] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/519089/
- -- Legoktm
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAl0S1oQACgkQ8QX4EBsF
Jpufrg/+J9RUUxRAtgJLEkyACE6GREis0eyEIZnWmMr3s9YpFPoqtWocFrUk6Wsn
W7d9Oda/8CW0/d894gGMn8LWIj9oWq2gMPWzCVFpg8uu3r4967qxBp+ba29uMOJw
Qpw6DhXtPvVAeUCy8P38Y5vM7TGmV+J1T5jDY21zimT1dRrJsI1KD+u/Ue3nYy/y
B1ic3i7vJfhYErdhHgN98ETXfXOaDx4rgd2N7PLjVNx3IYCC8LNiR8wSLuydfdbk
PLTT1bA2qi0h2wgcEr7Qtq9YstVotq8899rgKLtGDBwQi3qGNcdOgQGEMFDVfjfO
CsiWocj6s4oc3ScVj+Eb9xtvIqhNx+oRbWE1vKd4TmtSdyzpv6xadV60tq5qNFEY
I0cBDOWU5UFNHbvbyjK4dqIDEVhJ6LiEgLVBOj81U27s8mR4Dv/yFB3eac0ROk7p
gaEeOjfhtVU558XfpEsmu1H05VJT3kXNxK8y0UQOjy11SErzsXv6vDzyzLDJM/W7
WF0I4nyjeqVsBjLBN9li+5AnU3cAKVOCfZ+/aRYyg89Du//nJRjm+4lxnuPrGlaG
ES/nVUnkDZ9Yc/xA1yacm3Ytx9hpoY1mIZgxxxveyeU1KsNXAZ2BOGA2T7kU4yUw
Uyg+byYwI+1uVOjAVd3BInGV2R2/GmeIn9FOpthBaw8wcz0Y/8c=
=tU4+
-----END PGP SIGNATURE-----
Hi Everyone,
It's time for Wikimedia Tech Talks 2019 Episode 6!
Next month's talk will take place July 10, 2019 at 4:00 PM UTC.
Topic: A Deployment Pipeline Overview
Speaker: Alexandros Kosiaris, Senior Operations Engineer
Summary: The deployment pipeline project has been ongoing for a while,
sometimes with more resources poured into it, sometimes less, but it's
finally in a state that is ready to be used (it's already being used!).
This tech talk is about a presentation to wider technical audiences,
discussing the goals of the project, the implementation decisions and
how it's meant to be used and adopted by the deployers of services
(and eventually MediaWiki) in the coming months.
YouTube stream for viewers: https://www.youtube.com/watch?v=i0FTcG7PxzI
During the live talk, you are invited to join the discussion on IRC
at #wikimedia-office
Those in the SF office can watch this in R124.
You can watch past Tech Talks here:
https://www.mediawiki.org/wiki/Tech_talks
If you are interested in giving your own tech talk, you can learn more here:
https://www.mediawiki.org/wiki/Project:Calendar/How_to_schedule_an_event#Te…
Subbu.
(Standing in for Sarah Rodlund who is currently away on sabbatical)
I'm getting a new error today that was not happening with the identical
config yesterday.
With MW 1.31.1 and 1.31.2 I'm getting errors after installing dependencies
and extensions with Composer. I have the following composer.local.json:
```
{
"require": {
"mediawiki/semantic-media-wiki": "3.0.0",
"mediawiki/semantic-result-formats": "3.0.0",
"mediawiki/semantic-compound-queries": "1.2.0",
"mediawiki/sub-page-list": "1.5.0",
"mediawiki/maps": "6.0.3",
"pear/net_smtp": "1.8.0" <-- remove this when using MW 1.31.2
},
"extra": {
"merge-plugin": {
"include": [
"extensions/SyntaxHighlight_GeSHi/composer.json",
"extensions/Elastica/composer.json"
]
}
}
}
```
SyntaxHighlight_GeSHi and Elastica are both tracking their REL1_31
branches, which haven't changed in about a year. Despite that, yesterday
running `composer update` caused no issues. Today I started getting the
following error:
```
[Wed Jun 26 16:16:18.364715 2019] [php7:warn] [pid 12304] [client
my.ip.add.ress:46156] PHP Warning:
require(/opt/htdocs/mediawiki/vendor/composer/../jetbrains/phpstorm-stubs/PhpStormStubsMap.php):
failed to open stream: No such file or directory in
/opt/htdocs/mediawiki/vendor/composer/autoload_real.php on line 70,
referer: https://example.com/
[Wed Jun 26 16:16:18.364896 2019] [php7:error] [pid 12304] [client
my.ip.add.ress:46156] PHP Fatal error: require(): Failed opening required
'/opt/htdocs/mediawiki/vendor/composer/../jetbrains/phpstorm-stubs/PhpStormStubsMap.php'
(include_path='/opt/htdocs/mediawiki/vendor/pear/console_getopt:/opt/htdocs/mediawiki/vendor/pear/mail:/opt/htdocs/mediawiki/vendor/pear/mail_mime:/opt/htdocs/mediawiki/vendor/pear/mail_mime-decode:/opt/htdocs/mediawiki/vendor/pear/net_smtp:/opt/htdocs/mediawiki/vendor/pear/net_socket:/opt/htdocs/mediawiki/vendor/pear/pear-core-minimal/src:/opt/htdocs/mediawiki/vendor/pear/pear_exception:.:/usr/share/pear:/usr/share/php')
in /opt/htdocs/mediawiki/vendor/composer/autoload_real.php on line 70,
referer: https://example.com/
```
Using MW 1.32.1 and 1.31.2 I did the following:
```
rm -f ./composer.lock && composer install && sudo systemctl reload httpd
# no mention of phpstorm-stubs in output
# page loads fail
rm -f ./composer.lock && composer install --no-dev && sudo systemctl reload
httpd
# output includes: Removing jetbrains/phpstorm-stubs (dev-master)
# page loads succeed (no phpstorm-stubs)
composer install && sudo systemctl reload httpd
# output includes: Installing jetbrains/phpstorm-stubs (dev-master
9d01ce3): Cloning 9d01ce3476
# page loads succeed (phpstorm-stubs @ 9d01ce3)
composer update && sudo systemctl reload httpd
# output includes: Updating jetbrains/phpstorm-stubs dev-master (9d01ce3 =>
1b99060): Checking out 1b9906084d
# page loads fail (phpstorm-stubs @ 1b99060)
```
I need the httpd reload to invalidate opcache in my config. Based upon the
above it seems that the phpstorm-stubs that is getting required from
non-dev dependencies doesn't have issues, but the one from dev dependencies
does. Or perhaps something to do with Composer or with the Composer merge
plugin is causing one version of phpstorm-stubs to be checked out but the
autoloader to be setup for the other version. Any thoughts?
Thanks,
James
I wanted to restart the thank you Tuesday thread for this week. So heres my list of thanks:
Paladox, and releng, for all you do for maintaining Gerrit, Phabricator, and CI so we can keep making so many needed changes to mediawiki and other software/projects.
Andre, for sorting through hundreds if not thousands of tickets every day, without him, I’m sure phab would be a mess of unsorted tasks!
Finally, thanks to all the volunteers and staff that are constantly deploying, and creating patches to make MediaWiki and related projects as bug-free and user friendly as possible.
--
Devin “Zppix” CCENT
Volunteer Wikimedia Developer
Africa Wikimedia Developers Member and Mentor
Volunteer Mozilla Support Team Member (SUMO)
Quora.com Partner Program Member
enwp.org/User:Zppix
**Note: I do not work for Wikimedia Foundation, or any of its chapters. I also do not work for Mozilla, or any of its projects. **