https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-08-03
= 2016-08-03 =
== Product ==
=== Reading ===
==== iOS native app ====
* 5.0.5 was released last week.
** Reduced crash rate by 90%
** Several problems were identified after release and scheduled for 5.0.6
* 5.0.6 is going through regression today
** Shold be released by end of week
** Working with beta testers to verify fixes
https://phabricator.wikimedia.org/tag/ios-app-v5.0.6-hotfix/
* 5.1 is in Development
** Major features are iPad and Find in Page
https://phabricator.wikimedia.org/project/board/1736/query/open/
==== Android native app ====
* Current sprint: https://phabricator.wikimedia.org/project/view/2091/
* Next sprint (not yet full) :
https://phabricator.wikimedia.org/project/view/2142/
* Working on navigation overhaul, not blocked/blocking anyone to our
knowledge.
==== Mobile Content Service (MCS) ====
* Updating link handling
* Adding namespace and last modifier information to mobile-sections
responses.
* Added a few more languages to 'In the news' feed.
==== Reading Web ====
* Current sprint: https://phabricator.wikimedia.org/project/view/2115/
* Next sprint (not yet full) :
https://phabricator.wikimedia.org/project/view/2126/
* Mobile web language switcher button moving from bottom to top (with a tip
if user uses button on bottom of page which will remain for another several
sprints)
* Lazy loaded images for mobile web shipping approximately next 2-4 weeks
==== Reading Infrastructure ====
* Nothing to flag for now.
=== Community Tech ===
* Rolling out UCA collation + numeric sorting to English Wikipedia (
https://phabricator.wikimedia.org/T136150)
** Currently testing for German Wikipedia (
https://de.wikipedia.beta.wmflabs.org/wiki/Kategorie:UCA-Sortierung)
* Making improvements to InternetArchiveBot
* Had more meetings to hash out plan for cross-wiki watchlists
** Would you please add +tgr to any related tix? Mainly in thinking about
multiple watchlist support *down the road* (not now, understood that's not
part of your charter right now)
** Will probably need a dedicated database shard/hardward
=== Editing ===
==== Collaboration ====
* Blocked - None
* Blocking - Finishing up the ConfirmEdit work (
https://phabricator.wikimedia.org/T141300 ) which is blocking
ResourceLoader changes. Shouldn't require any action from you.
* Updates
** Nothing major to flag
** Some internal Echo-related improvements
==== Language ====
* Blocked:
** [TechOps/DB] Investigate increase in "readonly" saving errors in Content
Translation https://phabricator.wikimedia.org/T141090 - Need more guidance
on what Language Team can do here.
** [Analytics] Suddenly outrageous higher pageviews for main pages
https://phabricator.wikimedia.org/T141506 - Very important in statistics of
Compact Language Links.
*** Analytics response: we're happy to prioritize any infrastructure issues
that come out of this, but right now it needs more research attention,
Tilman and others are looking into it
* Blocking: None
* Updates:
** CX Dumps available soon
** Bug fixes for CX/CLL continue
** Apertium->Jessie in progress; Still lots of packages to go.
==== Parsing ====
* Ongoing migration of Parsoid cluster to Jessie and Node v4 (courtesy
Alexandros Kosiaris & Marko Obrovac). All Parsoid deploys on hold until
that finishes.
* Ongoing work on a bunch of projects, but nothing worth updating here at
this point.
=== Discovery ===
* No blockers
* Working on implementing bm25 searching
* Bugfixes for cross-wiki search (sections & namespaces)
* Refactoring & cleanup of CirrusSearch code
* Set up continuos cleanup process via cron (saneitizer)
* Stripping the question mark (?) from search queries is on the train this
week (https://phabricator.wikimedia.org/T133711)
== Technology ==
=== Analytics ===
* new AQS cluster is loaded back to February, when we get all the way back
to last July we'll switch over
** analytics-l thread on how much history to keep in Pageview API: (
https://lists.wikimedia.org/pipermail/analytics/2016-July/005317.html )
* Mediawiki history reconstruction algorithm scaled to handle enwiki, now
being productionized to do all wikis. NOTE to ops / DBAs: we will reach
out to you on the list to make sure it's ok to hit analytics-store
(dbstore1002 I think) like this
* refinery deployment with scap is being tested tomorrow: [[Phab:T129151]]
* EventLogging fixed to handle kafka restarts more graciously, being tested
in beta right now
=== Research ===
* ORES incident during deployment
** https://wikitech.wikimedia.org/wiki/Incident_documentation/20160801-ORES
** deployment to beta didn't show issues due to differences in
configuration between beta and prod
=== Technical Operations ===
* '''Blocked'''
** None
* '''Blocking'''
** None
* Updates
** Upgrading parsoid infrastructure to debian jessie, node 4.x
** There is going to be an varnish XKEY meeting
** prometheus work is ongoing
** thumbor is being introduced as a service in the infrastructure
=== Security ===
* Mediawiki 1.27.1 release delayed to next week
* captcha improvements
** https://phabricator.wikimedia.org/T125132
*** Matt mentions that Collaboration team owns users and logins
*** Matt is also doing some captcha refactoring:
https://phabricator.wikimedia.org/T141300
** https://phabricator.wikimedia.org/T141490
=== Services ===
* Parsoid in beta migrated to Jessie and Node 4, prod happening this week,
2 nodes already migrated
* Session storage / Auth service - discussion ongoing:
https://phabricator.wikimedia.org/T140813
* Maps Cassandra cluster: need to move it to 2.2.6
* Service-runner supports building deploy repo on Mac OS X now
=== Architecture / ArchCom ===
** **https://www.mediawiki.org/wiki/Architecture_committee/Status*
<https://www.mediawiki.org/wiki/Architecture_committee/Status>
** Last week: ArchCom meetings 2016W30: 2016-07-27 (Wed)
*** 1pm PDT (20 UTC) Planning meeting: [[Phab:*E236]]*
*** 2pm PDT (21 UTC) IRC #wikimedia-office: [[Phab:*E237]]*
***** [[Phab:T128602]] - *Create and deploy an extension that implements an
authenticated key-value store
** This week: ArchCom meetings 2016W31: 2016-08-03 (Wed)
*** 1pm PDT (20 UTC) Planning meeting: [[Phab:E250]]
*** 2pm PDT (21 UTC) IRC #wikimedia-office [[Phab:*E251]]*
***** [[Phab:T128351]]: Notifications in core*
=== RelEng ===
* '''Blocked'''
** None
* '''Blocking'''
** None?
* '''Updates'''
** New Scap release that uses logstash_checker.py coming—live on beta
already test please
** Lots of folks out this week, next week less folks out.
== Wikidata ==
* structured commons demo:
https://commons.wikimedia.org/wiki/Commons_talk:Structured_data#It.27s_aliv…
* deploying ArticlePlaceholder on more wikis (cywiki - Welsh) -
https://phabricator.wikimedia.org/T140725
== Fundraising Tech ==
* upgraded to mw 1.27 running on new hardware
* Installing new Redis cluster to replace ActiveMQ
* Rewriting queue code to work with Redis
* CiviCRM performance tuning
* CentralNotice cookie cleanup
Please also note the parent bug and rfc which blocks that. I've cced
wikitech in case anyone has an update.
https://phabricator.wikimedia.org/T39902
On 3 Aug 2016 5:14 a.m., "Stephen Niedzielski" <sniedzielski(a)wikimedia.org>
wrote:
> Hello! Thank you for the report! This issue is currently being tracked
> here[0]. We had hoped to fix this properly but maybe we should consider a
> temporary change in the client to handle this more gracefully.
>
> [0] https://phabricator.wikimedia.org/T119266
>
> On Wed, Aug 3, 2016 at 4:21 AM, Andy Mabbett <andy(a)pigsonthewing.org.uk>
> wrote:
>
>> The Android Wikipedia app shows Wikipedia's red links as blue links,
>> then returns a user-unfriendly 404 error page, with the somewhat
>> dishonest text "an unknown error occurred".
>>
>> Alternative, and better, behaviours would be one of (in no particular
>> order):
>>
>> * Show a red link; behave like desktop Wikipedia
>>
>> * Show a red link; when the link is selected, show a customised 404
>> page, which advises users how start a new article
>>
>> * Show red text, but make it non linking (i.e. "unclickable")
>>
>> * Remove the link and colour-styling, and render ordinary text
>>
>> * Fix the erorr page so it says "Sorry, that page does not exist",
>> with a link to a guide to starting a new article
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>>
>> _______________________________________________
>> Mobile-l mailing list
>> Mobile-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
Hello Everyone!
The Wikimedia Developer Summit will be taking place in San Francisco, CA,
USA between January 9th - January 11th. If you are interested in attending
this year please mark the date on your calendars.
More details will be added here soon about location, scholarships,
registration, accommodation, etc.
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2017?venotify=cre…
Please help by forwarding this to any other lists that might be interested
in this event.
Hi folks,
we in Hungarian Wikipedia have been watching new huwiki dumps by bot since
2011, so this page history:
https://hu.wikipedia.org/w/index.php?title=Sablon:A_dump_d%C3%A1tuma&offset…
clearly shows the freqency. Back in 2012 it took 8-10 days to create the
new dump. Now it takes one month. Are we less develeoped or do we have less
hardware than 4 years ago?
--
Bináris
Hi everyone
We have another ArchCom-RFC IRC office hour coming up tomorrow. This
week, we plan to discuss what parts of the notification infrastructure
in Echo we can/should move into MediaWiki Core (T128351). Brion is
shepherding this RFC, and pointed out on the task that we need "good
enough interfaces in core that other extensions don't have to depend
on Echo; also agreed that shipping Echo with core as a default
extension makes sense." Much of the recent discussion on that task
has been about what a reasonable level of abstraction, and avoiding
generalizing from a sample set of 1 (as Tgr puts it)
Discussion time/place:
#wikimedia-office: 2016-08-03 (Wednesday) 21:00 UTC (2pm PDT, 23:00 CEST)
More details about the meeting: <https://phabricator.wikimedia.org/E251>
More details about the topic: <https://phabricator.wikimedia.org/T128351>
Rob
p.s. ArchCom status updates continue on
<https://www.mediawiki.org/wiki/Architecture_committee/Status>
Hey,
This is the 15th weekly update from revision scoring team that we have sent
to this mailing list.
*New developments:*
- We'll no longer unnecessarily load the models into memory on the web
workers[1].
- We can now score multiple models against the same revision ID for
(essentially) free[2].
- Our precaching system will take advantage of this to drop load by
about 3X[3].
- Update wmflabs deploy repo for new version of ORES[4].
*Documentation & maintenance:*
- We completed deployment and maintenance docs for Wiki labels[5], which
means we've now got complete docs for our systems[6].
- We implemented basic continuous integration tests for the ORES
extension[7].
*Downtime:*
- We had a 1 hour long downtime while trying to deploy new code to
ores.wikimedia.org[8]. We've filed two critical tasks for making sure
we don't make the mistake again[9,10].
1. https://phabricator.wikimedia.org/T134606 - Score multiple models with
the same cached dependencies
2. https://phabricator.wikimedia.org/T139407 - Don't load models into
memory of web workers
3. https://phabricator.wikimedia.org/T141376 - Update precached to group
requests by model
4. https://phabricator.wikimedia.org/T141377 - Update wmflabs deploy repo
for new version of ORES
5. https://phabricator.wikimedia.org/T131768 - Wikilabels deployment docs
6. https://phabricator.wikimedia.org/T106271 - Document maintenance tasks
7. https://phabricator.wikimedia.org/T140455 - CI test for ORES extension
8. https://wikitech.wikimedia.org/wiki/Incident_documentation/20160801-ORES
9. https://phabricator.wikimedia.org/T141823 - Set up password on ORES Beta
redis server
10. https://phabricator.wikimedia.org/T141825 - Config beta ORES extension
to use the beta ORES service
Sincerely,
Aaron from the Revision Scoring team
Hi,
i just have a problem with confirmAccount. I would like to understand.
I use this extension. Just to confirm when someone ask createAccount, with
confirm email.
(My version of mediawiki 1.27)
1. User ask createAccount
2. i have this message in specialpage, BUT NOT in my MAIL
However i have in my localsettings.php :
$wgConfirmAccountContact = *"myemail**(a)gmail.com <http://gmail.com>"*;
3. In the email of user, he have confirmation and link to do it
==> Click and we can see on specialpage he confirmed.
4. Administrateur have to approuvate.
But when he do that, system return :
"Soit une erreur s’est produite sur la base de données d’authentification,
soit vous n’êtes pas autorisé à mettre à jour votre compte externe." (in
french, because i am)
Someone can help me to understand ?
thank's for all
yonnel
--
adresse mail : yonnel.kurtz(a)gmail.com
mobile : 07 61 72 79 12
Identifiant de société : Siren : 501 161 384
Code NAF : 722C
Siret : 501 161 384 00018
Code Insee : C75017862440
Hi,
i just have a problem with confirmAccount. I would like to understand.
I use this extension. Just to confirm when someone ask createAccount, with
confirm email.
(My version of mediawiki 1.27)
1. User ask createAccount
2. i have this message in specialpage, BUT NOT in my MAIL
However i have in my localsettings.php :
$wgConfirmAccountContact = *"myemail**(a)gmail.com <http://gmail.com>"*;
3. In the email of user, he have confirmation and link to do it
==> Click and we can see on specialpage he confirmed.
4. Administrateur have to approuvate.
But when he do that, system return :
"Soit une erreur s’est produite sur la base de données d’authentification,
soit vous n’êtes pas autorisé à mettre à jour votre compte externe." (in
french, because i am)
"An error occurred on the basis of authentication database or you are not
allowed to update your external account."
I don't understand, because i m sysop with *myemail**(a)gmail.com
<http://gmail.com/>*
can you hemp me ?
thank's !
yonnel
--
adresse mail : yonnel.kurtz(a)gmail.com
mobile : 07 61 72 79 12
Identifiant de société : Siren : 501 161 384
Code NAF : 722C
Siret : 501 161 384 00018
Code Insee : C75017862440
Hello,
I'm trying to include some output from
https://wikimedia.org/api/rest_v1/?doc into a Wikipedia
(xy.wikipedia.org) via a Javascript AJAX call.
Is it possible to have a JSONP output? I have not found any
documentation so far. Otherwise, would there be any other way (avoiding
a backend part, of course)?
Thanks,
--
Toni Hermoso Pulido
http://www.cau.cathttp://www.similis.cc
tl;dr: WMF Continuous Integration will have downtime on Tuesday August
2nd starting at about 16:00 UTC due to a WMF Labs infrastructure
upgrade. Don't expect Jenkins to report test failure/passing on your
changes during this time.
Apologies for the disruption,
Greg on behalf of the Release Engineering team
----- Forwarded message from Andrew Bogott <abogott(a)wikimedia.org> -----
> Date: Mon, 25 Jul 2016 11:57:15 -0500
> From: Andrew Bogott <abogott(a)wikimedia.org>
> To: labs-announce(a)lists.wikimedia.org, Release Engineering <releng(a)lists.wikimedia.org>, Operations Engineers <ops(a)lists.wikimedia.org>
> Subject: [RelEng] Labs Openstack upgrade next Tuesday, 2016-08-02, 16:00 UTC
> Reply-To: andrewbogott(a)gmail.com
>
> I'm going to upgrade our Openstack install from version 'Kilo' to
> version 'Liberty' next Tuesday. I've scheduled a 3-hour window for the
> process, although noticeable service interruptions should be shorter.
> Here's what to expect:
>
> - Tools services and existing Labs uses should be unaffected apart from
> brief ( < 1 minute) interruptions in network service.
>
> - Continuous Integration tests (Jenkins, Zuul, etc.) will be disabled for
> most of the upgrade window.
>
> - Creation/Deletion of new instances will be disabled for most of the
> window.
>
> - Wikitech and Horizon may error out occasionally and/or display
> inconsistent information. Users may need to refresh their web logins after
> the upgrade.
>
> Apart from fixing a few seldom-seen bugs, this upgrade shouldn't result in
> noticeable changes for Labs users. It will lay the groundwork for an
> upcoming Horizon upgrade, but that will be announced in a future email.
>
> -Andrew
>
>
>
> _______________________________________________
> RelEng mailing list
> RelEng(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/releng
----- End forwarded message -----
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |