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
Hello,
The following primary database masters will be switched over during the
next few weeks (more details at https://phabricator.wikimedia.org/T230788):
Impact:
*Writes will be blocked*
*Reads will remain unaffected*
These are the concrete days, hours and affected wikis:
* s8: 10th Sept from 05:00-05:30 UTC. The affected wiki is: wikidatawiki -
tracking task: T230762
* s2: 17th Sept from 05:00-05:30 UTC. The list of affected wikis is at:
https://raw.githubusercontent.com/wikimedia/operations-mediawiki-config/mas…
- tracking task: T230785
* s3: 24th Sept from 05:00-05:30 UTC. The list of affected wikis is at:
https://raw.githubusercontent.com/wikimedia/operations-mediawiki-config/mas…
- tracking task: T230783
* s4: 26th Sept from 05:00-05:30 UTC. The affected wiki is: commonswiki -
tracking task: T230784
If everything goes well, we do not expect to use those 30 minutes of
read-only and rather just a few minutes.
We will email send an email the day of each failover before and after it is
done.
Sorry for any inconvenience this might cause.
Hello,
The current primary master for m1 (db1063), which is mostly for internal
services + etherpad isn't in a great healthy status: it is an old host,
which needs to be decommissioned and which is having disks failing pretty
much every week (plus disks on predictive failure).
We have decided to fail it over one of the newer hosts, db1135:
https://phabricator.wikimedia.org/T231403
We have scheduled this switchover for: Tuesday 10th September at 16:00 UTC
This failover should be rather quick and would only take a few seconds
(while we re-load the haproxy) - during those few seconds, the following
services will be on read-only:
bacula
etherpadlite
librenms
puppet
racktables
rt
Communication will happen at #wikimedia-operations
If you are around at that time and want to help with the monitoring, please
join us!
Thanks
Hi Everyone,
It's time for Wikimedia Tech Talks 2019 Episode 7! This talk will take
place *Sept 4, 2019 at 6PM UTC*.
*Topic:* Documenting Wikimedia technical projects
*Speaker:* Sarah R. Rodlund, Technical Writer -- Developer Advocacy
*Summary: *
This talk will discuss what technical writers do and why they are critical
members of the Wikimedia technical community. You will learn more about the
skills needed to be a technical writer and how to build these skills by
participating on Wikimedia and other open source projects.
The talk will also cover some ongoing initiatives to improve technical
documentation for Wikimedia projects.
*YouTube stream for viewers:* https://www.youtube.com/watch?v=GKvyk4VAPb0
During the live talk, you are invited to join the discussion on IRC at
#wikimedia-office
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…
Many kindnesses,
Sarah R. Rodlund
Technical Writer, Developer Advocacy
<https://meta.wikimedia.org/wiki/Developer_Advocacy>
srodlund(a)wikimedia.org
The Search Platform Team
<https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> usually holds
office hours the first Wednesday of each month. Come talk to us about
anything related to Wikimedia search!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, Sep 4th, 2019
Time: 15:00-16:00 GMT / 08:00-9:00 PDT / 11:00-12:00 EDT / 17:00-18:00 CEST
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vyc-jvgq-dww
Hope to talk to you in a week!
Trey Jones
Sr. Software Engineer, Search Platform
Wikimedia Foundation
UTC-4 / EDT
Hello,
We are going to switchover m5 (wikitech) primary database master on *Tuesday
3rd September at 13:00 UTC *https://phabricator.wikimedia.org/T229657
This switchover will also affect some Cloud services that will be handled
on a different announcement.
The current master (db1073) is an old and out of warranty hosts with
several disks on predictive failure, it needs to be decommissioned.
We will be failing over db1073 to db1133, a newer and more powerful host.
We expect this to take around 15 minutes (or just a few seconds if
everything goes fine).
*Impact: *
*- Writes will be blocked during the switchover*
*- Reads will remain unaffected.*
Communication will happen on #wikimedia-operations IRC channel.
Thanks
Manuel.
The 1.34.0-wmf.20 version of MediaWiki is blocked.
https://phabricator.wikimedia.org/T220745
The new version is not deployed anywhere yet. It will not be deployed until
these issues are resolved:
* ServiceContainer.php: Circular dependency when creating MobileFrontend
service "AMC.UserMode > AMC.Manager > FeaturesManager > UserModes >
AMC.UserMode" https://phabricator.wikimedia.org/T231014
* DefaultPreferencesFactory.php: Global default '' is invalid for field
incubatortestwiki-code https://phabricator.wikimedia.org/T231029
* /w/api.php... ErrorException from line 0 of : PHP Notice: Unable to
unserialize ... Size of serialized string ... exceeds max
https://phabricator.wikimedia.org/T231071
* L10n cache is completely broken https://phabricator.wikimedia.org/T231183
Once these issues are resolved train can start.
Additionally, I've found this errors in logs, but since they are not new,
they are not blocking the train.
* Assert.php: Bad value for parameter $responses: must have as many
responses as requests https://phabricator.wikimedia.org/T231023
* Assert.php: Bad value for parameter $oldContent: must be a
TextContent|null https://phabricator.wikimedia.org/T231084
* WikibaseClient.php: PHP Notice: Undefined index:
https://phabricator.wikimedia.org/T231089
Thank you for your help resolving these issues!
-- Your humble train toiler, Željko
I see that in some classes, like WANObjectCache, most methods are declared
final. Why is this? Is it an attempt to optimize?
The problem is that PHPUnit mocks can't touch final methods. Any ->method()
calls that try to do anything to them silently do nothing. This makes
writing tests harder.
If we really want these methods to be marked final for some reason, the
workaround for PHP is to make an interface that has all the desired
methods, have the class implement the interface, and make type hints all
refer to the interface instead of the class. But if there's no good reason
to declare the methods final to begin with, it's simplest to just drop it.
Hello all,
Meta Wiki has page called Limits to configuration changes <
https://meta.wikimedia.org/wiki/Limits_to_configuration_changes> that is
currently merely a list of declined requests. I believe it should be
explaining why declining happens rather than document what happened, since
the later is already documented in Phabricator.
As such, I've decided to update it, since I'm active in that field. Since
it is more inspired by the current version and not based on it (it's a
complete rewrite). I would like to invite everyone to read the update at
https://meta.wikimedia.org/wiki/Limits_to_configuration_changes/Update_2019,
and join the discussion at
https://meta.wikimedia.org/wiki/Talk:Limits_to_configuration_changes, or
also to edit the update itself. Once we agree it's good to go, the text can
be changed.
Martin Urbanec