https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-07-27
= 2016-07-27 =
== Product ==
=== Reading ===
==== iOS native app ====
* 5.0.5
** passed regression, but we foud a bug in beta. Patching and pushing a new build today.
** expected release to Apple store later this week
* Development of 5.1 is in progress
* Planning of 5.2 is in progress
==== Android native app ====
* Stable release containing the feed planned for Thursday
* Work on navigation overhaul is underway
==== Mobile Content Service (MCS) ====
* Added public feed endpoints to MCS documentation: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/RESTBase_services_for_ap…
==== Reading Web ====
==== Reading Infrastructure ====
* Waiting on translatewiki to be ready for https://gerrit.wikimedia.org/r/#/c/280945/
=== Community Tech ===
* Deploying numeric category sorting to testwiki today, others to follow
* Working with CLs to find guinea pig wiki for PageAssessments before deploying to enwiki
* Finishing work on CopyPatrol tool (https://tools.wmflabs.org/copypatrol)
=== Editing ===
==== Collaboration ====
* Blocked - None
* Blocking - Florian and I are working on refactoring how ConfirmEdit handles OutputPage, in preparation for a refactoring Timo is doing. This may be a breaking change, so follow at https://phabricator.wikimedia.org/T141300 . Otherwise, no change.
* Updates
** Mention notifications: Wikimedia Germany is working on notifications for mention failures (when you apparently intended a mention, but it is not counted as one), and successful mentions. They will also allow you to mention yourself. We're coordinating with them on these tasks.
** Echo changes related to moderation.
** Warning when you leave a Flow board without saving.
** Working on updating the Echo badges.
==== Language ====
* Blocked: Apertium Jessie Packages (Tech Ops).
* Updates:
** Improvements in CX and CLL (ULS) continue.
** Parallel Corpora Dumps work is restarted.
== Technology ==
=== Analytics ===
* edit history reconstruction algorithms done, short demo tomorrow, scaling them to handle all wikis is next
* event bus schema work is approaching completion, the new schemas feed nicely into edit history and handle the requirements of the services team
* work on moving refinery deployment to scap3 is ongoing
* loading of the new more performant AQS cluster is progressing nicely now
=== Technical Operations ===
* '''Blocked'''
** None
* '''Blocking'''
** None
* Updates
** Got some problems during a network maintenance. T140770
** Minor issues in labs with OpenLDAP memory leaks
** Working on upgrading puppetmaster infrastructure to 3.8
** Started looking into vmod_xkey for varnish
** Planning for a parsoid host (wtp*) upgrade to jessie with Parsing. Scheduled for 1st week of August
=== Security ===
* Working on pingback privacy statement with Legal
* Mediawiki 1.27.1 nearly complete; to be released August 3
* Mediawiki 1.27.2 tracking and prep has begun
* Security releases wlll now be on a two month schedule
=== Services ===
* '''Blocked'''
** None
* '''Blocking'''
** None
* Updates
** Kafka upgrade to 0.9 ongoing.
** Session storage & authentication service planning and prototyping: https://phabricator.wikimedia.org/T140813
=== Architecture / ArchCom ===
* https://www.mediawiki.org/wiki/Architecture_committee/Status
* Recent 2016W29: 2016-07-20 (last week)
** ArchCom Planning meeting: [https://phabricator.wikimedia.org/E234 E234]
*** Notes: [https://www.mediawiki.org/wiki/Architecture_committee/2016-07-20 Architecture committee/2016-07-20]
** ArchCom-RFC office hour: [https://phabricator.wikimedia.org/E235 E235]
*** Agenda: [https://phabricator.wikimedia.org/T126641 T126641]: [RFC] Devise plan for a cross-wiki watchlist back-end
* Upcoming 2016W30: 2016-07-27 (today)
** ArchCom Planning meeting: [https://phabricator.wikimedia.org/E236 Phab:E236]
*** Notes: [https://www.mediawiki.org/wiki/Architecture_committee/2016-07-27 Architecture committee/2016-07-27]
** ArchCom-RFC office hour: [https://phabricator.wikimedia.org/E237 Phab:E237]
*** Agenda: [https://phabricator.wikimedia.org/T128602 T128602 Create and deploy an extension that implements an authenticated key-value store]
=== RelEng ===
* Blocking
** None
* Blocked
** None
* Updates
** Chad proposed a new icinga alert to detect files owned by root in the mediawiki deployment repository: https://gerrit.wikimedia.org/r/#/c/301327/
** Zeljko on vacation until Aug 15th
** Antione going on vacation next week until Aug 21st
== Discovery ==
* '''Blocking''': none
* '''Blocked''': none
* Mostly working on refactoring & technical debt
* Trey published survey of top unsuccessful searches: https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Top_Unsuccessful_Sea…
* Vacations
* State of the Map & DataViz hackathon (https://www.mediawiki.org/wiki/DataViz_Seattle_hackathon)
== Wikidata ==
* working on prototype for structured commons
* Daniel working on multi-content revisions
== Fundraising Tech ==
* Not blocked.
* EMcNaughton is on the cusp of running a dedupe script on CiviCRM--it'll still take several weeks to finish, going at a few hundred contacts per minute, but now we think that even the first iteration will catch a majority of the duplicates.
* LZia might be doing some analysis on CentralNotice banner numbers, in a part-time volunteer project for WLM. She'll be the first analyst to use some of our exciting new data streams, like "banner history".
* Queue overhaul is coming along steadily, no blockers.
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
At https://phabricator.wikimedia.org/T47126 Verdy_p wrote:
"So I think that writing "[[Link]]s" (or "[[Target|Link]]s") instead of
"[[Target|Links]]" (or "[[Link|Links]]") is just an old (deprecated) trick
of MediaWiki used by (lazy) wiki redactors, we cannot recommand using it:"
I think this may be of a wider interest. Is [[Link]]s syntax really
deprecated? I never read about this anywhere.
>From when?
Is it subject to removal?
Should all guides be updated and links corrected by bot?
--
Bináris
Hi everyone
In our upcoming ArchCom-RFC IRC office hour meeting, we plan to
discuss T128602, which discusses how to implement an authenticated
key-value store in MediaWiki. Dmitry Brant wrote the original RFC,
and Brad Jorsch refined it, listing out many questions on the Phab
task (e.g. Action API endpoint or RESTbase service, how should we
store the data, what limits should we have, what sort of abuse
prevention strategy should we employ)
Discussion time/place:
#wikimedia-office: 2016-07-27 (Wednesday) 21:00 UTC (2pm PDT, 23:00 CEST)
More details about the meeting: <https://phabricator.wikimedia.org/E237>
More details about the topic: <https://phabricator.wikimedia.org/T128602>
Rob
p.s. ArchCom status updates continue on
<https://www.mediawiki.org/wiki/Architecture_committee/Status>
I'm wondering if MS will pull citations from Wikipedia and/or make use of
Wikidata.
I'm also wondering if this will decrease Wikimedia site traffic in a
similar way to how search engine knowledge panels may have decreased
Wikimedia site traffic, particularly in this case from users who have
access to MS Office.
https://blogs.office.com/2016/07/26/the-evolution-of-office-apps-new-intell…
Pine
Hi,
https://phabricator.wikimedia.org/T129442 says to belong to
Tool-Labs-tools-Pageviews but how to find the repository for it, if I
want to work on it? Gerrit does not find anything when I enter this
sring in its repository search.
Is there any tool or tutorial for this question?
Purodha
tl;dr: Scap will deploy to canary servers and check for error-log spikes in the next version (to be released Soon™).
In light of recent incidents[0] which have created outages accompanied by large, easily detectable, error-rate spikes, a patch has recently landed in Scap[1] that will:
1. Push changes to a set of canary servers[2] before syncing to proxy servers
2. Wait a configurable length of time (currently 20 seconds[3]) for any errors to have time to make themselves known
3. Query Logstash (using a script written by Gabriel Wicke[4]) to determine if the error rate has increased over a configurable threshold (currently 10-fold[5])
Big thanks to the folks that helped in this effort: Gabriel Wicke, Filippo Giunchedi and Giuseppe Lavagetto, Bryan Davis and Erik Bernhardson (for their mad Logstash skillz)!
It is noteworthy, that in instances where expedience is required—we're in the middle of an outage and who cares what Logstash has to say—the `--force` flag can be added to skip canary checks all together (i.e. `scap sync-file --force wmf-config/InitialiseSettings 'Panic!!'`).
The RelEng team's eventual goal is still to move MediaWiki deployments to the more robust and resillient Scap3 deployment framework. There is some high-priority work that has to happen before the Scap3 move. In the interim, we are taking steps (like this one) to respond to incidents and keep deployments safe.
Hopefully, this work and the error-rate alert work from Ori last week[6] will allow everyone to be more conscientious and more keenly aware of deployments that cause large aberrations in the rate of errors.
<3,
Your Friendly Neighborhood Release Engineering Team
[0]. https://wikitech.wikimedia.org/wiki/Incident_documentation/20160601-MediaWi… is the recent example I could find, but there have been others.
[1]. https://phabricator.wikimedia.org/D248
[2]. https://gerrit.wikimedia.org/r/#/c/294742/
[3]. https://github.com/wikimedia/scap/blob/master/scap/config.py#L19
[4]. https://gerrit.wikimedia.org/r/#/c/292505/
[5]. https://github.com/wikimedia/scap/blob/master/scap/config.py#L18
[6]. https://gerrit.wikimedia.org/r/#/c/300327/
Hello!
The next CREDIT showcase is Wednesday, 3-August-2016 at 1800 UTC (1100 SF).
https://www.mediawiki.org/wiki/CREDIT_showcase
Please add your demos to the Etherpad.
See you soon!
-Adam
Hi,
Daniel and I have been spending a lot of time in the last week preparing a
smooth upgrade
path for Gerrit to a new (and supported version). The migration will be
coming soon but I could
use your help testing things in the meantime.
https://gerrit-new.wikimedia.org/r/
The database is a snapshot from last week and the git data is up to date as
of a few hours
ago. Please use this opportunity to test the new installation and make sure
it works for you.
Make a change. Do some reviews. Do the things you usually would.
Again, this is snapshot data so: A) Don't worry about messing up the real
install, and B) Don't
expect any changes to persist after the migration.
If nobody identifies any major blockers, we'll go ahead and set an upgrade
time for the
immediate future.
Thanks so much!
-Chad & Daniel