The Release Engineering team's goal for the April-June 2016 quarter is
to move everything that is currently deployed with Trebuchet over to
Scap. With the release of Scap 3.1.0, everything that is deployed via
Trebuchet can be ported to Scap—it supports git-fat, restarting
services, and there is even a puppet provider.
== What is the timeline? ==
We have made tasks for all of the existing projects that are deployed
via Trebuchet[0], and the goal is to move these all by **2016-06-30**
(AKA the End of The Quarter™).
If we missed your project that is deployed via Trebuchet, please add a
task with the #scap3 tag in phabricator.
== What is Scap? Why are we moving to it? ==
Scap is a tool that the Release Engineering team has been working on
as a successor to the salt-based Trebuchet deployment system.
* Stable and secure SSH-based command and control
* Detailed error logs available from every target node
* Built on tools that everyone is familiar with—SSH and Git
== What does it mean to move to Scap? ==
To assist with the move from Trebuchet to Scap:
* We have written documentation, including a quick start setup guide [1]
* Release Engineering folks are available to help with migrations,
questions, concerns in the #scap3 channel on freenode
== Why isn't Release Engineering just porting everything all by their
lonesome? ==
We're hoping that by the end of the quarter, not only will we get all
projects migrated, but we also want folks to be familiar with Scap and
know how to troubleshoot their own deployments. In the end, the goal
is to scale knowledge of how to use Wikimedia's deployment tooling to
the wider organization instead of a handful of people. "Teach a person
to fish"[2] and all...
<3,
Tyler Cipriani
WMF Release Engingeering
[0] https://phabricator.wikimedia.org/project/view/1824/
[1] https://doc.wikimedia.org/mw-tools-scap/scap3/quickstart/setup.html
[2] https://en.wiktionary.org/wiki/give_a_man_a_fish_and_you_feed_him_for_a_day…
Hi, back from the Hackathon in Jerusalem, where technical collaboration
worked at its best. :)
I have been asking hackathon participants about their opinions on the Code
of Conduct, especially among volunteers that haven't participated in the
draft. The replies could be mainly classified in two groups: "about time --
sorry that I couldn't follow all the discussion" and "right, but is there
really a problem...?".
Since there have been some questions about the types of problems we have in
our technical spaces, I have tried to provide an overview at
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Problems_in_the_W…
Please have a look. The fact that Wikimedia technical spaces seem to have
less problems than other corners of the movement doesn't mean that there
are no problems at all. Andre and I deal with reports of different types
basically every month.
For us, the proposal for a Code of Conduct with a process to handle reports
by a community committee represents a better process than the current
ad-hoc approach that the WMF Developer Relations team has to maintain in
response to the complaints we receive.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello,
The WMF’s technology department has for this quarter the goal of testing
and temporarily switching the main operational data centre from Eqiad
(located in Chicago) to Codfw (located in Dallas)~[1,2]. This includes both
back-end-processing as well as serving live traffic from it.
As a part of this effort, we are scheduling a switch-over for RESTBase and
its back-end services, including: Parsoid, the Mobile Content Service,
CXServer, Mathoid, Citoid, Apertium and Zotero~[3]. Technically, it will
not be a real switch-over per se, because we will keep all of those
services active in both DCs. However, external traffic will be directed to
the Dallas DC only.
=== When is it and what does it mean for me? ===
The switch-over test is planned for this Thursday, 2016-03-17. We have
allotted a three-hour window for this~[4]. There is nothing users should
do before or after the switch; it will be transparent for them. There are
two things users should note, though:
1) At the time of the switch-over, users might receive error responses for
a while (both 4xx and 5xx status codes). While we will test most of the
things ahead of time, we cannot test the actual traffic shifting, so small
bumps might be noticed.
2) After the switch to the Dallas DC, users will likely see their response
latencies slightly elevated. During the test, some requests might
experience a slightly larger latency. This will occur because all of the
services that will be responding to live requests still need to contact the
main MediaWiki cluster, which will remain in Eqiad (the other DC) until a
complete switch-over of the infrastructure is performed. However, given the
multiple levels of caching, the 40 ms of penalty to go cross-DC for an
uncached API request does not seem too taxing.
=== Wait, what about my service X running in WMF production? ===
If you are a service owner of one the aforementioned services, there are no
explicit actions you should take prior to, during or after the switch-over
test. This test could, however, affect your service depending on whether it
usually serves live traffic or is mostly operational during various
internal updates. MediaWiki and JobQueue processing will still be performed
in Eqiad, so in the latter case your service should not see a change in the
usage pattern. If, however, your service is mostly in charge of responding
to live requests coming through RESTBase, those will be handled by
instances in Codfw. However, as these services are full replicas of their
Eqiad counterparts and are stateless, no major breakage will happen.
Should you have any questions or concerns, don’t hesitate to contact us
here or on IRC (#wikimedia-services @ freenode).
Best,
Marko Obrovac, PhD
Senior Services Engineer
Wikimedia Foundation
[1]
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q3_Goals#Techn…
[2] https://phabricator.wikimedia.org/project/profile/1723/
[3] https://phabricator.wikimedia.org/T127974
[4]
https://wikitech.wikimedia.org/wiki/Deployments#Thursday.2C.C2.A0March.C2.A…
Hello everyone,
Related pages feature has been in beta for over two months now, the future
of the feature depends on our discussions. While we currently don't have a
clear process for deciding collaboratively on an all languages product,
Alsee and the reading team have put together this document on meta [0], as
a request for comment, seeking comments and ideas on modifications
required, and how to further test the feature. In fact, we are not sure if
an rfc is the best strategy to move forward with product decisions, but
lets see how the discussion evolves, and we might explore the need for a
different process, as we move on with this one.
We managed to translate a brief introduction about the topic, please feel
free to fully translate the document and/or further promote the discussion
on your wiki. We are trying hard to avoid having an English centric
discussion for a feature that could be available across all language
projects, and while we don't have a clear solution for this, we are trying
this method as an experiment, where at least our communities can leave
comments in their preferred language if they aren't comfortable writing in
English but they can understand it.
Please check the page, help with translation or promotion in your
Wikipedia, and most importantly, comment on how you think it can evolve. :)
Lets see how this works!
All the best,
M
[0] https://meta.wikimedia.org/wiki/Requests_for_comment/Related_Pages
Hello,
The Jenkins slaves had grunt-cli provisioned which is often used by the
npm test command. If you get a Jenkins job to fail with:
sh: 1: grunt: not found
Simply add grunt-cli to your project devDependencies and the next build
have it installed. Example:
https://gerrit.wikimedia.org/r/#/c/275823/1/package.json,cm
The change removing grunt-cli is:
https://gerrit.wikimedia.org/r/#/c/280974/
--
Antoine "hashar" Musso
TL;DR: Parsoid isn't i18n friendly and uses English keywords instead of
localized.[1] Is it a bug or feature? Please voice your opinion!
Longer version:
For some funny reasons Parsoid is reading arrays from "right to left"[1],
that is, it uses the LAST alias of the magic words rather than the first
one[2].
One of the reasons for this is because in English the shorter "thumb" is
preferred compared to the long "thumbnail". However, instead of fixing
MessagesEn.php to define thumb as the first option, parsoid uses the last
option.
This choice result in all other wikis using the English alias (which
appears last in magic words) rather than the localized one - so Parsoid
isn't i18n friendly.
However there are different POVs regarding the correct solution for it:
1. Use English aliases in all projects - these are the most used aliases
[and one of the reasons is people copying code from enwiki or using biased
tools such as Parsoid]
2. Use localized aliases - keep the article content and syntax in the same
language. This is especially important for non-latin languages with
different alphabet.
And there is a consensus for English being bad choice for RTL languages as
it cause mixed directional content which should be avoided. So if we go
with 1 choice, RTL languages should be exception.
I believe there is a cultural point of view here, and would like to hear
what do you think (especially non RTL and non English speakers): Do you
prefer mini (German), vignette (French), miniaturadeimagen (Spanish), мини
(Russian) instead of thumb (for example)?
I did some dump-minning to get the usage statistics:
https://phab.wmfusercontent.org/file/data/bskxfupspqo64dnnkdr7/PHID-FILE-v4…
And based on this I wrote a python script to suggest a reordering of the
aliases by usage[3], so if choice 2 is selected, we can merge[2] and all
languages will use the preferred choice.
[1] https://phabricator.wikimedia.org/T53852
[2] https://gerrit.wikimedia.org/r/#/c/244254/3/lib/wts.LinkHandler.js
[3] https://gerrit.wikimedia.org/r/#/c/247914
On Apr 1, 2016 11:00 PM, "C. Scott Ananian" <cananian(a)wikimedia.org> wrote:
>
> On Fri, Apr 1, 2016 at 3:24 PM, Legoktm <legoktm.wikipedia(a)gmail.com>
wrote:
>
> > I've written a patch[1] that introduces a new feature to the Thanks
> > extension called "feelings". When hovering over a "thank" link, five
> > different emoji icons will pop up[2], representing five different
> > feelings: happy, love, surprise, anger, and fear. Editors can pick one
> > of those options instead of just a plain thanks, to indicate how they
> > really feel, which the recipient will see[3].
> >
>
>
> Only one of these options?
> --scott, surprised, happy & a bit fearful
>
> --
> (http://cscott.net)
Not angry, just disappointed
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Some of us at the hackathon ran into this old bug again:
https://phabricator.wikimedia.org/T62835
namely, the MediaWiki API currently completely forbids cross-origin
requests in the CORS config except for whitelisting authenticated requests
from our own domains, whereas it could also allow non-authenticated
cross-origin requests from non-whitelisted domains.
This would allow browser-side JavaScript code on other sites (tools,
mashups, whatever) to get anonymous data from Wikipedia, Wikidata, etc
without resorting to JSONP (an old-school hack whereby JSON data is loaded
via a callback in a <script> tag).
JSONP is fragile, and is unsafe for other sites to rely on, as it's a
potential cross-site scripting vector for them.
CORS is pretty mature these days, and should be something we can rely on. I
hope. :)
-- brion