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
Hi, what would you like to see in gerrit or improved? I've been working been working on developing a plugin that pull's in zuul's status into PolyGerrit. See the running demo at https://imgur.com/a/uBk2oxQ . Im also planning on adding "recheck" and "check experimental" as buttons to PolyGerrit's ui to improve CI. This will help new users who can recheck (and existing users that either forgot they can type this or haven't learned yet).
Note that i cannot promise that anything suggested in this thread will be worked on, but i can try my best.
See tasks https://phabricator.wikimedia.org/T214068 and https://phabricator.wikimedia.org/T214631 .
Hello all,
I am Manimaran. I am Free Software Activist and also android developer. I
try to make app for contributing Wiktionary. Which help to record audio
then upload to commons.
I share my efforts to my blog. I face some problem on development. Any one
can help me.
*Blog* :
https://manimaran96.wordpress.com/2019/01/06/spell4wiki-mobile-app-to-recor…
*Source code* : https://github.com/manimaran96/Spell4Wiki
*APK file* :
https://github.com/manimaran96/Spell4Wiki/blob/master/apk_file/spell4wiki_1…
*Issue*
- When Uploading audio I got an error message* ->
*{“error”:{“code”:”permissiondenied”,”info”:”The
action you have requested is limited to users in one of the groups:
[[Wikipedia:Autoconfirmed users|Autoconfirmed users]],
[[Wikipedia:Administrators|Administrators]], [[Wikipedia:User access
levels#Confirmed|Confirmed users]].”,”*”:”See
https://en.wikipedia.org/w/api.phpfor API usage. Subscribe to the
mediawiki-api-announce mailing list at <
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce>
for notice of API deprecations and breaking changes.”},”servedby”:”mw1226″}
- But My User name is confirmed via mail. Also Have permission to
upload. Then I don’t know why comes this type of issue.
- Also trying with other wikipedians username same error comes all of
them.
This is just another small reminder that, because the servers which host
tiles.wmflabs.org and wma.wmflabs.org (wikiminiatlas) and overpass-wiki
run on a version of the OS (Ubuntu Trusty) that is no longer supported (and
hasn't been available for new instances since november 2017).
These services need maintainers and support by community members in order
to keep them alive after dec 18th (after which wmflabs will phase out those
versions) and before the EOL of early 2019 of the OS. Unfortunately it
seems no one is stepping up so far to convert these machines.
This issue is tracked at https://phabricator.wikimedia.org/T204506
As I was curious, I looked around on the tile server a bit and used what I
could find to update
https://wikitech.wikimedia.org/wiki/OSM_Tileserver#Technology_stack
This is all the information that I could gather, but i'm FAR from sure if
that is complete information and if I would break anything with a rebuild
basing myself on that info, so any information on missing elements etc.
would be appreciated. I've not gotten around to looking at wikiminiatlas.
If the services are not rebuild then likely they will just disappear at
some point for all layer variants. This includes the mapnik, black and
white, hill shading, hike bike layers. As I have no idea how many users of
these services there are, it is hard to say what the effect of that would
be.
DJ
Hi folks,
Based on comments that I received on Wikimedia-l, I would like to invite
people to a casual online meetup one hour before the monthly WMF Metrics
and Activities Meeting.
There will be no set agenda. You can come with questions or ideas that you
would like to discuss. Please be willing to listen to questions and ideas
from other Wikimedians.
I will host the meeting with the Zoom software. You can join with software
or by using your phone. If you join by phone then your phone number will be
visible to other participants.
The primary language of the meeting will be English, but if people would
like to communicate in diverse languages then that is okay too. We can
facilitate translation by text chat. Many Wikimedians, myself included, are
multilingual in varying degrees, so we might try to have live
interpretation also.
Here is information about how to connect:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/136978210
Or iPhone one-tap :
Argentina: +543415122188,,136978210#
Or Telephone:
Dial (for higher quality, dial a number based on your current
location):
Argentina: +54 341 512 2188
Australia: +61 (0) 2 8015 2088 or +61 (0) 8 7150 1149
Canada: +1 647 558 0588
Hong Kong, China: +852 5808 6088
France: +33 (0) 1 8288 0188 or +33 (0) 7 5678 4048
Germany: +49 (0) 30 3080 6188 or +49 (0) 30 5679 5800
Israel: +972 (0) 3 978 6688
Italy: +39 069 480 6488
Japan: +81 (0) 3 4578 1488 or +81 524 564 439
Mexico: +52 229 910 0061 or +52 554 161 4288
Spain: +34 84 368 5025 or +34 91 198 0188
Sweden: +46 (0) 7 6692 0434 or +46 (0) 8 4468 2488
Russia: +7 495 283 9788
United Kingdom: +44 (0) 20 3051 2874 or +44 (0) 20 3695 0088
US: +1 408 638 0986 or +1 646 558 8665
Meeting ID: 136 978 210
International numbers available: https://zoom.us/u/ekaPibJIy
The first "Wikimedia Café" meetup will be on 30 August 2018, at 17:00 UTC /
10:00 Pacific.
Let me emphasize that the environment won't be like this
<https://en.wikipedia.org/wiki/File:West_Hartford,_Connecticut_health_care_r…>,
so please don't feel intimated if you are nervous about public speaking.
(If a conversation feels to me like it is becoming uncivil or intimidating,
then I will ask the debaters to quiet themselves or to move to somewhere
else.) The meeting will generally have an environment that is more like this
<https://en.wikipedia.org/wiki/File:Caf%C3%A9_M%C3%A9lange,_Wien.jpg> or
this
<https://en.wikipedia.org/wiki/File:Takamatsu-Castle-Building-Interior-M3488…>.
I anticipate that few people will come, which is okay. I hope that if you
come then you will enjoy the environment and conversation.
Until next time,
Pine
( https://meta.wikimedia.org/wiki/User:Pine )
Hi, i am pleased to announce that the zuul-status plugin is now available for gerrit 2.16+.
This plugin integrates the zuul status json response into gerrit displaying the jobs lined up and running. It's similar to how you would see it on https://integration.wikimedia.org/zuul/ apart from it will only show for your change only. This will improve the experience as you won't need to leave your change to get a live feed of your change as it progresses through checks.
You can see the demo at https://imgur.com/a/uBk2oxQ
Plugin at https://gerrit-review.googlesource.com/admin/repos/plugins/zuul-status
First commit: https://gerrit-review.googlesource.com/c/plugins/zuul-status/+/212103
The plugin uses PolyGerrit's ui rather then GWTUI as GWTUI has been removed upstream (from gerrit 3.0) and because PolyGerrit provides XSS protection.
Hello Everyone,
I am working on improving developer productivity! Specifically, I am aiming
to improve the local development environment.
Satisfaction with the local development environment got the second lowest
score in the developer satisfaction survey, and we (Release Engineering)
would like to find out which things about it you like, and which are
troublesome. In order to do so, we need your help! I’d love to have the
opportunity to interview you about your local setup and/or observe how you
interact with it.
Please send me an email if you’d like to participate, and I or one of my
colleagues will schedule some time with you.
I’m looking forward to our conversations. This is a chance for you to shape
the local development environment, so please don’t hold back :)
Outcomes resulting from the interviews (non personally identifiable
information) will be made available after analysis has been completed.
--
Jeena Huneidi
Software Engineer, Release Engineering
Wikimedia Foundation
A few months ago I switched our TimedMediaHandler's config to support the
newer, more bandwidth-efficient VP9/Opus variant of WebM and to use these
preferably over the older VP8/Vorbis version when creating scaled,
playback-ready derivatives.
(This does not affect upload support -- you may continue to upload video
files in WebM VP9, WebM VP8, or Ogg Theora formats, with either Vorbis or
Opus audio.)
Conversions of existing files on Commons ran in the background for some
weeks, finishing in November. I'm now running a final pass for
high-resolution files and any files on other wikis that didn't get a
conversion yet, in preparation for removing the VP8 derivatives in the next
couple of weeks to free storage space.
This should have relatively little visible effect for users, unless someone
is relying on the particular derivative files with extensions like
".360p.webm"; the new versions are named like ".360p.vp9.webm".
Note that IE 11 users using the "WebM Media Foundation Components for IE
<https://www.webmproject.org/ie/>" will not be able to play back the new
VP9/Opus files natively, as this driver has never been updated for VP9 or
Opus. IE 11 users will receive low-resolution, slow JavaScript-based video
playback instead. If you find this is troublesome, the recommended solution
is to switch to any other browser.
Third-party MediaWiki + TimedMediaHandler users should be aware that the
defaults are changing, and in future the VP8-specific support and code
paths may be removed. TimedMediaHandler will probably change a lot in the
coming months with upcoming WebVTT subtitle format, a streamlined
videojs-based player, and hopefully more!
-- brion
At the Extension:Scribunto/Lua reference manual, at several places,[1]
it is pointed out that the lua-libs should use the form 'mw.ext.NAME'.
This creates visual noise in the code. Any lib included should have a
extension page, thus it has already been given an unique name. In
addition, only the libraries that need to be preloaded are added to
the mw-structure, and those are the extensions. The ext-addition is
like saying "this is an extension and it is only extensions that needs
to be added to the mw-struct so we make it abundantly clear that this
is an extension".
The only cases where a name can collide is if some external lib is
included, that external lib has the same name as an extension, and if
someone in addition preloads the external lib. The chance is quite
frankly pretty slim, as there are rather few external libs that makes
sense to preload in this environment, especially as preloading imply
some kind of interaction with the environment. That means it is an
extension.
I guess I'm stepping on some toes here…
So to make it abundantly clear, not 'mw.ext.NAME' (or 'mw.ext.NaMe',
or 'mw.ext.name') but 'mw.name' (lowercase, not camelcase). If the
call is a constructor or some kind of builder interface, then
'mw.name(…)' is totally valid. I do not believe it is wise to turn the
lib into an instance by the call, but it can return an instance, it
can cache previously returned instances, and it can somehow install
the instance(s) in the current environment.
An extension should have any pure root libs at 'pure/name.lua' and
additional libs at 'pure/name/additional.lua', where 'pure' is
resolved in the 'ScribuntoExternalLibraries' hook.
[1] https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#Ext…
what about abuse by administrators and stewards ?
From: Moriel Schottlender
Sent: Monday, January 7, 2019 7:53 PM
To: Wikimedia developers ; Wikitech-ambassadors(a)lists.wikimedia.org
Subject: [Wikitech-l] Changes to the Block
paradigm
Greetings,
Have
you written code that deals with or depends on user blocks? Read on.
=
TL;DR: =
The new “Partial Blocks” feature has fundamentally changed the
way MediaWiki
considers what “block” means; any code that handles blocks
should consider
whether the questions it is asking are still valid or should
adjust its
expectations. Please read for more details.
= Preamble
=
A couple of months ago, as part of the Anti Harassment Tools
team’s
continued work on improving the general experience of our users
and
providing more robust tools to administrators, an RFC to enable
“Partial
Blocks[1]” has passed and has been implemented in MediaWiki,
affecting the
way blocking users operates.
While the actual feature,
enabling the blocking of users for specific pages
and namespaces, will be
slowly rolled out as part of our rollout and
testing plans, the change has
resulted in a complete change of paradigm for
what “block” means throughout
our code.
= Change of paradigm =
Until recently, Block was fairly
straight forward; whether a block was done
on an IP range or a specific user,
the question the code would ask is “is
the user blocked from this action” and
the answer will be a boolean yes or
no, depending on whether the user was
blocked from the wiki and whether the
action was a blockable
action.
With the new Partial Blocks feature, that question is now more
elaborate.
We are giving admins and wikis in general much more robust options
when
deciding to block IPs or users. “Sitewide” block is no longer the
only
option. Now, a user can be blocked from editing a specific page, and
soon
from a specific namespace. There are also blocks that prevent a
specific
action, such as uploading files or creating new pages.
This
means that the question “is the user blocked” is no longer accurate.
In most
cases, the question should be “is the user blocked from the action
on this
page”, because users may receive a block that is not sitewide, but
from a
specific page or set of pages.
= What we worked on =
The Anti
Harassment Tools team has been working diligently on making sure
that the new
blocking behavior does not produce obvious regressions in
production, and
does not add to any still existing inconsistencies. In
cases where we
identified a clear mismatch, we’ve tried to either fix it
outright or alert
the code owners to adjust.
If we have missed any iteration or use-case,
please open a Phabricator
ticket and add the ‘anti-harassment’[2] tag to it.
If the use-case is
sensitive or identifies a current loop-hole in the way
blocks work, please
make it a security ticket and alert us and the relevant
team immediately.
= General steps forward =
While the team is
following up on making the code clear and robust and
fixing what we’ve
identified as paradigm-changes to deal with, there are
still many instances
where the changes required to the code are not
straight-forward or clear.
Some extensions ask whether a user is blocked
and may need to change the way
that the product’s “business logic” behaves.
These are cases where we
cannot make the decision for the codebase. We
encourage you to look at your
product and consider adjusting if necessary.
= General guidance
=
We’ve identified some areas that may help code owners adjust their
products
to properly take advantage of the new feature and adjust to the
new
paradigm change. This list is not exhaustive, but may help you spot
areas
in your code that can easily be changed:
* User::isBlocked() has
changed its meaning, and its use cases should be
re-examined depending on
what your code intends to check.
For the most part, if there’s a Title object
available,
User::isBlockedFrom() is a good option. Otherwise, consider
using
User::getBlock() and Block::isSitewide()
* Block::prevents( ‘edit’ )
is an operation that doesn’t make sense
anymore, because a block on the
‘edit’ action now depends on context (the
title).
* Determining whether a
block prevents a user from editing their own user
talk page has
changed.
For a sitewide block, if the $wgBlockAllowsUTEdit config is false,
then the
block prevents the user editing their user talk page, but if it is
true,
then whether they can edit their user talk page depends on
the
ipb_allow_usertalk flag on the block. For a partial block to a page
or
pages, these flags are not taken into account: if the user’s talk page
is
specified as a blocked page, then they cannot edit their user talk page;
if
it is not, then they can edit it. Block::prevents( ‘editownuserpage’
)
should therefore not be checked for a partial page block[3]. We plan
to
deprecate that parameter officially, please consider if this affects
your
code.
* Please check that any classes that extend Action or
FormSpecialPage
return the correct value for requiresUnblock().
To
summarize, in general, the meaning of asking whether a block exists
has
changed, and any code piece that needs this information should
adjust
itself to account for partial blocks, depending on its
goals.
Thank you,
Moriel, on behalf of the Anti Harassment Tools
Team
References:
[1] Partial
blocks:
https://meta.wikimedia.org/wiki/Community_health_initiative/Per-user_page,_…
[2]
Anti Harassment tools
board:
https://phabricator.wikimedia.org/project/view/2660/
[3] For a
discussion of this, see: https://phabricator.wikimedia.org/T210475
--
Moriel
Schottlender (she/her)
Senior Software Engineer, Tech
Lead
Community Tech and Anti Harassment Tools
@mooeypoo (IRC /
Phabricator)
_______________________________________________
Wikitech-l
mailing
list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
