"I came across a patch from a user who was keen to move himself from
"Patch contributors" to "Developers" in the MediaWiki CREDITS file
[1]. It had been sitting there for over a year. He doesn't seem to
have been active since. I don't know what to do with it. It made me
think.
Do we have it documented anywhere how we use this credits file and why
we feel the need to distinguish between Developers and Patch
Contributors? It seems like a recipe for disaster in my opinion as it
can only lead to hurt feelings due to contributors feeling unfairly
treated. https://www.mediawiki.org/wiki/Special:Version/Credits leads
with 'We would like to recognize the following persons for their
contribution to MediaWiki." - if someone is not in that list are they
not as important?
If we keep these files we should probably explain the rules to what
adding names looks like within these files and what the process to
adding your name is (can I add myself? Is there a process like getting
+2?)
To take another extreme, we might consider abandoning such a file in
favour of something automatically generated. Things like
https://github.com/wikimedia/mediawiki/graphs/contributors do a far
better job at allowing people to see who contributed to a tool and
making people feel like their work is rewarded.
On a slightly related note, can we abandon the practice of putting
names inside files themselves? I see this practice in JavaScript and
PHP files throughout core (grep for @author). As Team Geek [2] (great
read btw) says "unlike other collaborative pieces of creative work...
software keeps changing even after it's "done". So while listing
contributors credits at the end of a movie is a safe and static thing,
attempting to add and remove names from a source file is a
never-ending exercise in insanity". For similar reasons this practice
gives an impression of ownership of a file/code review
responsibilities (which are not always true) and risks hurt feelings.
[1] https://github.com/wikimedia/mediawiki/blob/master/CREDITS
[2] http://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=9781449302…
Hi all,
Etherpad [0], our real-time colaborative editing tool suffered an
outage due to what we only know for now was database corruption. This
was detected shortly after it happened 14:27 UTC and we (ops in charge
of the service and the database) worked to reestablish the service.
As the service continued crashing despite our efforts, we decided to
recover a database backup from 2016-06-22 01:00:01 UTC. The service is
now back up and working since 16:11 UTC, but that means that you may
have lost a day and a half of edits in the current available etherpad
[0].
I understand that that may cause a lot of inconveniences, specially
for the people at Wikimania. *We are now trying to recover more than
that*, but as the corruption could come back, or not all could be
recovered, and people need the service the plan is the following:
- Keep the current pads as is, not delete or add anything from now.
You can continue using etherpad now as usual.
- If possible, recover the last days of edits on a separate location.
See [1] for progress if you are affected.
Sorry for the inconveniences. Please, more than ever, follow the
recommendation we added at the beginning of every empty pad:
> "Keep in mind as well that there is no guarantee that a pad's contents will always be available. A pad may be corrupted, deleted or similar. Please keep a copy of important data somewhere else as well"
The reason for this is that wiki content has proper HA and redundancy,
etherpad does not.
Again, my most sincere apologies,
[0] <https://etherpad.wikimedia.org/>
[1] <https://phabricator.wikimedia.org/T138516>
--
Jaime Crespo
<http://wikimedia.org>
Hi,
the first image scaler based on Debian jessie is now enabled in
production. Despite other changes this also provides an update
of librsvg to 2.40.16 which fixes several long-standing bugs in
SVG rendering:
https://phabricator.wikimedia.org/T44090https://phabricator.wikimedia.org/T64987https://phabricator.wikimedia.org/T97758https://phabricator.wikimedia.org/T111815
(Please note that this currently only applies to one out of eight
systems, I'll send a followup once all scalers are migrated).
This has been tested quite a bit and no problems were found, but if
you notice anything unusual related to image/SVG scaling (e.g. due to
font changes) please drop a note in #wikimedia-operations or file a
Phabricator task and add the Operations project.
Cheers,
Moritz
== tl;dr ==
On June 29th git.wikimedia.org (running Gitblit) will redirect all
requests to Phabricator. The vast majority of requests will be correctly
redirected.
== What is happening? ==
In an effort to reduce the maintenance burden of redudant services we
will be removing git.wikimedia.org. The software that has been serving
git.wikimedia.org, Gitblit, has given our Operations team many headaches
over the years[0] and now that we have all repositories hosted in
Phabricator[1] there is no reason to keep Gitblit around. Phabricator's
Diffusion (the name of the code browser) provides the needed
functionality that Gitblit served (mostly viewing/browsing repositories,
something which Gerrit does not do).
== When will it happen? ==
June 29th
https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20160629T1600
== How could this affect me? ==
Potentially, you use an unpopular (in the sense of not used often)
feature of Gitblit that is not supported in Diffusion. This should be
unlikely.
Potentially, a link you follow that pointed to somewhere on
git.wikimedia.org will not redirect correctly. This is also unlikely as
we (mostly @Danny_B and @Paladox) took great care to update many
mediawiki.org templates along with providing very robust redirect
rules[2]. If you find one that isn't working, please let us know (along
with the original url and, if possible, the desired target in
Diffusion).
One known issue to call out: Diffusion does not list commits by person.
However Differential (the code-review tool) does this (not just for new
commits). There is no easy/maintainable way to redirect those,
unfortunately.
Something else broken? Please file a task in Phabricator in the
#Diffusion project[3].
Thanks,
Greg, on behalf of WMF Release Engineering (and all the volunteers who
helped along the way (and Ops!))
[0] eg: https://phabricator.wikimedia.org/T73974
[1] https://phabricator.wikimedia.org/diffusion/
[2] https://phabricator.wikimedia.org/T137224
[3] https://phabricator.wikimedia.org/project/profile/53/
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hey all,
Following a brief chat in IRC, I've proposed[0] adding curl to the list of
PHP extensions required by MediaWiki, and Chad thought it'd be a good idea
to get wider thoughts before merging.
Right now we have some features that require curl (it's probably the #2
issue third parties have with installing VisualEditor, for instance, after
mis-matched versions).
We already require mbstring (as discussed in March) alongside xml, ctype,
json, and iconv. If you have an opinion, please weigh in on the task.[1]
[0] - https://gerrit.wikimedia.org/r/#/c/294259/
[1] - https://phabricator.wikimedia.org/T137926
J.
--
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-06-29
= 2016-06-29 =
== Product ==
=== Reading ===
==== iOS ====
* 5.0.5 - found a regression on Monday, fixing and testing in beta for the
rest of the week. Expecting to deploy next week
* 5.1 (no changes)
** In development - expected release early August
** Potential blocker for release is GeoData API improvements
https://phabricator.wikimedia.org/T137178 We are working with Discovery to
get this in for our release (blocker INTERACTIVE TEAM)
==== Android ====
* Feed work continues -- will ship to beta channel optimistically by end of
this week, otherwise sometime next week
==== Mobile Content Service ====
* Will need the services team to activate the feed endpoints in the public
REST API before shipping the feed (but work is still in progress)
==== Reading Web ====
* Image lazy loading on mobile web fawiki and ukwiki
* Image lazy loading plus reference lazy loading coming soon to mobile web
tlwiki (approx 30-June-2016 or 4-5 July 2016)
* Wikidata article descriptions added to top of page on mobile web cawiki,
coming to mobile web plwiki 30-June-2016
* Mobile main pages were errantly getting desktop formatting in some places
for a while, now fixed
==== Reading Infrastructure ====
* waiting for Language to say whether they will take T111486 (Update
Translate to use AuthManager)
=== Editing ===
==== Parsing ====
* Parsoid:
** Over last couple weeks, working on a bunch of link rendering /
serialization issues (mostly edge cases) in Parsoid
** About to resume work on native implementation of <gallery> extension --
Arlo has an initial patch in gerrit which needs a round of updates. Should
unblock multimedia & VE work on gallery support once this is done.
** At Wikimania hackathon, Scott worked on an update to support a more
detailed Templatedata format field for serializing transclusions -- this is
not finalized yet and the spec needs to stabilize before this can land.
* Core parser:
** Tim working on a side-by-side preview tool to let editors see how a page
would look with Tidy and with HTML5depurate -
https://gerrit.wikimedia.org/r/#/c/296182/ ... feedback welcome,
especially on the UI aspects or desirable features. Please take a look and
leave comments on the patch.
== Technology ==
=== Technical Operations ===
* '''Blocking'''
** None
* '''Blocked'''
** by noone
* Updates
** Slow week, wikimania
** Some work with interactive/discovery on maps
** some non user affecting changes in our firewalling setup
** Working with LE to review/upload on apt.wikimedia.org apertium related
packages
=== Security ===
* One usability bugs for Ex::OATHAuth in progress (T138423) (help
reproducing appreciated)
* Two-factor usability survey prep continues
* Reviews: 3d2png
* Three additional reviews will have feedback added this week: T130233,
T129175, T132934
=== RelEng ===
* Blocking
** None?
* Blocked
** Gallium phase out questions: https://phabricator.wikimedia.org/T133300
*** Pasted some IRC talk from chase
*** Other input welcome
** CI Documentation publication: https://phabricator.wikimedia.org/T137890
*** Mostly needs some network expertise
** Scandium disk space: https://phabricator.wikimedia.org/T138955
* Updates
** Train is back on track, wmf.8 to group1 today
** 1.27 release is out (yay!)
** Scap3 migrations continue (if you have questions, ask us! :))
=== Analytics ===
* Rebooting stat boxes and analytics cluster to upgrade kernel (security
patch)
* Working on testing a much faster way to load Cassandra directly from
Hadoop
* Cleaning up mediawiki page and user history is still ongoing
* Andrew, Madhu, and Nuria will be out until next week
== Discovery ==
* '''Blocking''': none
* '''Blocked''': none
* TextCat A/B test still running
* New research on typing in wrong character set:
https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Typing_on_the_Wrong_…
* Testing software upgrade for logstash.wikimedia.org at kibana4.wmflabs.org
- backward incompatible upgrade
* WDQS now deployed with scap3
* Everybody's welcome to rate query relevance in Discernatron:
https://discernatron.wmflabs.org/
=== Interactive Team ===
* Wikidata Query service support in geo shapes service is being deployed
* Heavy maps refactoring - might have broken cached pages and will need a
regen
* Need to start deploying shared GeoShapes & tabular data soonish
* RELENG: please make configuration for services available to devs, not
just ops
; '''blocking'''
* Potential blocker for release is GeoData API improvements
https://phabricator.wikimedia.org/T137178 We are working with Discovery to
get this in for our release (blocker INTERACTIVE TEAM)
== WIkidata ==
* Blockers: See T107595.
* Most of the team attended Wikimania.
** Relevant discussions about our plans for a Wikidata-powered Wiktionary:
https://phabricator.wikimedia.org/T986
** WMF support for multi content revisions was promised:
https://phabricator.wikimedia.org/T107595
TL;DR: Gadgets should use HTTP POST for purge/rollback/markpatrolled
actions.
-------
Some gadgets still use HTTP GET for page purge requests.
In order to better facilitate multi-datacenter traffic routing [1] and to
better comply with web standards [2],
these types of requests should use POST instead. GET is considered, by
specification, to be a "safe method".
Since purge requests perform database writes and potentially significant
rendering updates, they should use a
state-changing HTTP method. Also, achieving of our multi-datacenter goal as
planned involves leveraging safe
HTTP methods to route request to either the closest or the primary
datacenter for optimal performance.
Most of such requests to MediaWiki already require POST, but "purge" is one
of the exceptions. There is no
compelling reason for this to be exceptional, however. Exposing a URL
parameter that does database writes,
reparsing, and cache updates simply by following a link (especial with no
CSRF token) encourages bad practice
(having links that bypass cache) and the risk of performance problems if
such a link becomes popular.
Rollback requests should also use HTTP POST given that it results in a page
edit. The database operations are
far more complex than purge, so in a multi-datacenter system, such requests
(if using HTTP GET) could have much worse performance depending on the
client's location (even if very close to a datacenter). Ideally, reversion
tools would use the
API for rollback, instead of index.php.
The markpatrolled action, like rollback, also involves a GET request with a
token parameter. The core JavaScript
MediaWiki provides already uses the API with POST, but users without
javascript (and some Gadgets) are still using
HTTP GET. The Gadgets should be converted to POST.
Purge, rollback, and markpatrolled support both POST and GET right now.
Gadgets still using GET for these actions
should be converted to use POST instead.
There is a task at T135170 [3] for MediaWiki to require POST for purge
requests.
Also see T88044 [4] for the same requirement for rollback requests.
[1] https://phabricator.wikimedia.org/T92357
[2] https://tools.ietf.org/html/rfc7231#section-4.2.1
[3] https://phabricator.wikimedia.org/T135170
[4] https://phabricator.wikimedia.org/T88044
--
-Aaron
Yaron Koren has proposed to reopen the "Unacceptable behavior" section
(https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Suggested_change_…).
His perspective and mine are given on the talk page.
In brief:
* He disagrees with how "marginalized and otherwise underrepresented
groups" and "encouraged" are handled in the original text.
* I support the current text and process, and have explained why on the
talk page.
Thanks,
Matt Flaschen
Hi,
Are there any on-going efforts to log JavaScript errors to the server logs?
Every once in a while we see very hard to reproduce errors in the console
that we're not sure how often are actually happening, and that makes us
think that there may be other errors happening that we're not coming across
(or other people savvy enough to open the console and post a bug).
There are open source projects like sentry we could inspect and adapt a
client library for our purposes and log to EventLogging or somewhere else (
https://docs.getsentry.com/hosted/clients/javascript/).