Change 389747 had a related patch set uploaded (by Phuedx; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Limit download button to Google Chrome

https://gerrit.wikimedia.org/r/389747

@ovasileva remember... images will not appear in the printed version of mobile (history in T162414).
Are we rolling out without addressing this problem? If not, we need a task for that first.

@Jdlrobson - for now, we're okay with downloads without images. That said, I was under the impression that it would be very difficult to tackle. What are our options in terms of adding images? Do we have any straightforward way of doing this, or should we start with a spike?

Change 389747 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Limit download button to Google Chrome

https://gerrit.wikimedia.org/r/389747

Change 391040 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@wmf/1.31.0-wmf.7] Limit download button to Google Chrome

https://gerrit.wikimedia.org/r/391040

Prior to rolling out, make sure email is sent to wikitech

Why? What is the purpose of the email?

NOTE: Deployment date should be Nov 15

Why? Why not today to allow us more time to revert if needed?

Change 391041 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[operations/mediawiki-config@master] Enable the download icon on all wikis

https://gerrit.wikimedia.org/r/391041

Why? What is the purpose of the email?
Why? Why not today to allow us more time to revert if needed?

This is a large change and we want to make sure the community is informed before deploying. More detail can be found under the CL task T180114: Notify community of upcoming PDF button deployment. We will be sending the update Nov 14 (tomorrow) and can go forward with the deployment on the 15th.

Clarified the intention of the last checkbox item per today's standup.

^ This can't be done until Wednesday, 15th, right?

Change 391040 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@wmf/1.31.0-wmf.7] Limit download button to Google Chrome

https://gerrit.wikimedia.org/r/391040

Mentioned in SAL (#wikimedia-operations) [2017-11-15T19:16:13Z] <catrope@tin> Synchronized php-1.31.0-wmf.7/skins/MinervaNeue/resources/skins.minerva.scripts/init.js: Limit download button to Google Chrome (T179529, T179914) (duration: 00m 49s)

Change 391041 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable the download icon on all wikis

https://gerrit.wikimedia.org/r/391041

Mentioned in SAL (#wikimedia-operations) [2017-11-15T19:34:14Z] <catrope@tin> Synchronized wmf-config/InitialiseSettings.php: Enable Minerva download icon on all wikis (T179914) (duration: 00m 48s)

There was quite a big jump over the lunch break after deploying (which happened around 11.30am) but it's now calmed down a little
https://grafana.wikimedia.org/dashboard/db/eventlogging-schema?orgId=1&var-schema=Print
I'm now seeing double the rate before the deploy.

cc @mforns - any idea why i'm seeing that several hours of no events?!

@Jdlrobson I'm surprised that there's no jump between last week and this
week, given the button.

This is a bit late in the game, but did we ever test the Schema:Print instrumentation for mobile/Minerva?
Recall that there had been a bit of confusion at T169730: Define and implement instrumentation for printing on desktop web, which (as the task name still says) was initially intended for desktop only, but came to be extended to mobile later. However, that was only after @bmansurov and I had done our testing rounds.

Or to put it differently: Has someone checked that the onBeforePrint/ matchmedia event (cf. T171162#3457776 ) behaves as expected for Chrome mobile on Android?

In T179914#3764603, @Jdlrobson wrote:

...

Not sure what happened between 9 and 12:40 (but a similar no events and spike happened on Popups https://grafana.wikimedia.org/dashboard/db/eventlogging-schema?orgId=1&from=now-24h&to=now&var-schema=Popups)

I followed up on #wikimedia-analytics; this was caused by yesterday's migration of the EventLogging master database.

In T179914#3765969, @Tbayer wrote:

...

I followed up on #wikimedia-analytics; this was caused by yesterday's migration of the EventLogging master database.

...and I understand the timestamps in the actual EventLogging table (in MySQL) are not affected, i.e. should not show that gap; Grafana instead reflects the time when the events were processed internally later in the pipeline (and in that sense is always a bit less accurate, even when the pipeline is not stopped entirely as in this case).

@Jdlrobson, @atgo - possibly could be lower than expected due to caching as well, although I'm still not seeing a very large increase. Perhaps we should double-check the schema as @Tbayer suggested

Or to put it differently: Has someone checked that the onBeforePrint/ matchmedia event (cf. T171162#3457776 ) behaves as expected for Chrome mobile on Android?

I don't see any specific record of us testing Chrome on mobile (I don't actually see much QA on T169730), but we did implement matchMedia per suggestion of @bmansurov specifically for Chrome.Llooking at the data, I am seeing events from Android Chrome on Minerva on the mobile domain. We wouldn't be getting any events if that wasn't working.

I think we should still do a manual check that the events are being sent in correctly as a part of signoff by going through the events. Do we have a good way of doing this from a phone?

Seems like we would need a separate task to set up a debug parameter and then try testing it manually

You can manually test this already for increased confidence.
To do so put the following code in your user minerva.js to force on bucketing:

mw.storage.session.set('mwuser-sessionId',15);

You will then be able to see the results in the database after waiting 5 mins or so.

select * from Print_17199246 where event_sessionToken = '15'

Test with that as you wish, but given the wide spread of Android versions (4-10) and families (Samsung, Nexus, Asus, Moto G...) in the data we are already collecting for Android [1] I see no need to be worried this is not working correctly. @Tbayer is there anything specific that's making you doubt the data?

[1] select * from Print_17199246 where userAgent LIKE "%Chrome%" AND userAgent NOT LIKE "%iOS%" AND timestamp LIKE "20171115%" and event_skin = 'minerva'

I should note that usage seems a little higher today on Minerva (4x already) and already has surpassed yesterday's usage (1301 events) despite it being only 6pm UTC time:
minerva 4187
This fits a hypothesis of HTML caching/discoverability of a new feature.

It's still very low compared to desktop though (19424 events)

In T179914#3766905, @Jdlrobson wrote:

Or to put it differently: Has someone checked that the onBeforePrint/ matchmedia event (cf. T171162#3457776 ) behaves as expected for Chrome mobile on Android?

I don't see any specific record of us testing Chrome on mobile (I don't actually see much QA on T169730),

There was quite a bit of testing, see e.g. the link in my previous comment. But only on desktop, as far as I'm aware. Hence the question.

but we did implement matchMedia per suggestion of @bmansurov specifically for Chrome.Llooking at the data, I am seeing events from Android Chrome on Minerva on the mobile domain. We wouldn't be getting any events if that wasn't working.

"some data is arriving" is not the same as "correct data is arriving".

In T179914#3767547, @Jdlrobson wrote:

You can manually test this already for increased confidence.
To do so put the following code in your user minerva.js to force on bucketing:

mw.storage.session.set('mwuser-sessionId',15);

You will then be able to see the results in the database after waiting 5 mins or so.

select * from Print_17199246 where event_sessionToken = '15'

Thanks for these instructions!

Test with that as you wish, but given the wide spread of Android versions (4-10) and families (Samsung, Nexus, Asus, Moto G...) in the data we are already collecting for Android [1] I see no need to be worried this is not working correctly. @Tbayer is there anything specific that's making you doubt the data?

I'm surprised to see that kind of logic put forward, given all the past data problems the team has experienced due to instrumentation bugs that could have been easily avoided with some direct testing before deployment. Specifically in the case of this schema (see e.g. T169730#3471912 ) and more generally in recent months (we also discussed this for a while at last month's offsite) we have been resolving that direct testing is needed, and it has already started to pay off.

Anyway, since this task is about deploying the feature per se, I'm going to close it now, having verified that the increase in events did not break EventLogging, i.e. the last AC. I have added a point about instrumentation testing to T179915 instead.