[00:44:12] (PS8) Cdentinger: WIP mustache l10n [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/258099 (https://phabricator.wikimedia.org/T120992) [01:19:11] (CR) Awight: "That's definitely working for me." (1 comment) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/258099 (https://phabricator.wikimedia.org/T120992) (owner: Cdentinger) [01:20:49] (CR) Cdentinger: WIP mustache l10n (2 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/258099 (https://phabricator.wikimedia.org/T120992) (owner: Cdentinger) [09:04:14] (PS1) AndyRussG: KVStore: Wrap accesses to LocalStorage in try/catch blocks [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/259986 (https://phabricator.wikimedia.org/T121738) [09:06:24] (CR) Gilles: KVStore: Wrap accesses to LocalStorage in try/catch blocks (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/259986 (https://phabricator.wikimedia.org/T121738) (owner: AndyRussG) [09:08:53] (PS2) AndyRussG: KVStore: Wrap accesses to LocalStorage in try/catch blocks [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/259986 (https://phabricator.wikimedia.org/T121738) [09:09:49] (CR) AndyRussG: KVStore: Wrap accesses to LocalStorage in try/catch blocks (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/259986 (https://phabricator.wikimedia.org/T121738) (owner: AndyRussG) [16:23:18] AndyRussG|mob: nice sleuthing! Just doing some queries to get counts by page title and impressions for matching refer(r)er, for Barack_Obama vs Cowboy_Bebop (popular page on 12/11 with few images) [16:56:01] ejegg: hey! just saw your ping to the mobile me...! Yeah great approach [16:57:11] Also got some excellent feedback on queries on -analytics yesterday, that could help get more precise data [16:57:17] if I can get the where clauses right, anyway! first query came back with more impressions than views on Barack_Obama, so I tightened up the referer clause [16:57:38] AndyRussG: ah, nice! I'll take a look at the channel archives [16:58:41] ejegg: ah K... the most significant easy one is to filter nocookies using the X-analytics field: https://wikitech.wikimedia.org/wiki/X-Analytics [16:58:55] on both sides of the query (pageviews and impressions) [16:59:17] That'll get rid of bots, or at least scrapers that don't process banners/JS [16:59:35] ooh, nice one [16:59:49] It'll also get rid of people in incognito mode, but if we get rid of them on both sides of the query, it's fine [16:59:58] k [17:00:37] other are better namespace filtering, and filtering for clients that don't support our JS [17:00:49] (or rather that our JS doesn't support) [17:01:41] I'm waiting for Krinkle to come online, hopefully soon, to get feedback on gilles's idea of putting CN loading back in the head [17:03:24] yeah, seems like a lot of our assumptions are violated with it loading so late [17:07:48] ejegg: if only there were a way to directly measure network latency on pageviews and impressions! [17:08:31] (PS9) Cdentinger: mustache l10n [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/258099 (https://phabricator.wikimedia.org/T120992) [17:08:44] yeah... I guess you could do expensive joins on referer to see when page assets are loaded relative to the page [17:09:02] like, referer + client_ip or something [17:14:28] ejegg: https://wikitech.wikimedia.org/wiki/Analytics/Cluster/Hive/QueryUsingUDF [17:14:55] Say for filtering namespace properly, or unsupported useragents [17:15:27] ah, that's handy! [17:15:37] yeah! [17:16:00] ejegg: also, if we think there's a chance of getting CN loading moved back into the head, we'll need this: https://gerrit.wikimedia.org/r/#/c/259986/ [17:16:14] (wraps LocalStorage in try/catch) [17:16:34] oh, I wonder if user_agent_map is actually populated in the stored data, or if it's running a function when I filter on it [17:16:50] hmmm good question [17:17:09] I actually know like next to nothing about the internals of all this stuff [17:17:13] that try/catch looks smart in any case [17:17:14] Just that there much data [17:17:31] ejegg: yeah it's a known bug and all, affects users who completely disable coooookies [17:17:58] But if we want our code to run like much sooner, we definitely gotta fixit [17:19:31] whew, that's a lot of places to fix! Guess not everything checks for isAvailable? [17:19:55] ejegg: well, everything should, but just incase [17:20:00] Maybe I went overboard [17:20:15] ehh, it's minified [17:21:03] I really don't know the full behaviour, maybe on some platforms in some cases it throws for certain calls and not others? Who knows [17:21:48] it's annoying that RL doesn't deal with the quota exceeded errors [17:24:28] AndyRussG: looks like touching localStorage at all, even without looking at properties, can throw a SecurityError exception: http://www.w3.org/TR/webstorage/#the-localstorage-attribute [17:24:49] So you're probably not overboard [17:25:10] * ejegg retracts lifeboats [17:25:32] ejegg: heheh [17:25:43] ejegg: hmmm yeah that's what I've experienced [17:35:17] Fundraising Sprint Yo La Tengo, Fundraising Sprint Zapp, Fundraising-Backlog, MediaWiki-extensions-DonationInterface: iframe not appearing for some people (confirmed modern browsers) - https://phabricator.wikimedia.org/T112181#1890915 (MBeat33) The donor in #192774 used https://donate.wikimedia.or... [17:42:06] D'oh! The page with fewer images had worse impressions ratios. I guess there could be all sorts of reasons for that [17:43:57] O_o [17:47:24] ejegg|afk: whoa! [17:47:31] * AndyRussG zzzzzzzzzzz 15 min [17:47:53] P.S. hi, back soon [18:03:21] K4-713: meganhernandez: hi! ah hmm I thought there'd be FR standup today, just saw there isn't [18:03:44] AndyRussG: There's one right now. [18:03:58] Maybe they trimmed down the list back to normal. [18:04:37] K4-713: it's not on FR calendar [18:05:04] AndyRussG: Fixing! [18:05:11] AndyRussG: Hi [18:05:27] Hey! How's SF? [18:05:42] AndyRussG: You should be invited now. [18:05:50] K4-713: K there [18:06:19] Good. I'm working from 'home' this one day though. [18:06:43] Reading back scroll here and in -perf, will reply in -perf [18:06:59] Krinkle: K sorry unexpected meeting, done in 30 min, thx!!!! [18:09:21] (CR) Krinkle: KVStore: Wrap accesses to LocalStorage in try/catch blocks (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/259986 (https://phabricator.wikimedia.org/T121738) (owner: AndyRussG) [18:12:44] ejegg: AndyRussG: Yeah, access to localStorage should always be wrapped in try/catch. I recall bringing this up in the initial review of KVStore. It isn't related to incognito mode however (it works fine there and is simply deref'ed after the session by the browser). It mainly fails in three scenarios: 1) Old iOS for unpredictable reasons, 2) Firefox [18:12:44] preference for "No cookies allowed", 3) LocalStorage is full. [18:13:24] (continueing in -perf) [18:14:24] (CR) Ejegg: KVStore: Wrap accesses to LocalStorage in try/catch blocks (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/259986 (https://phabricator.wikimedia.org/T121738) (owner: AndyRussG) [18:29:42] (CR) Krinkle: KVStore: Wrap accesses to LocalStorage in try/catch blocks (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/259986 (https://phabricator.wikimedia.org/T121738) (owner: AndyRussG) [18:35:45] Fundraising Sprint William Shatner, Fundraising Sprint X-Ray Spex, Fundraising Sprint Yo La Tengo, Fundraising Sprint Zapp, and 2 others: Track email clickthroughs on donate wiki - https://phabricator.wikimedia.org/T114010#1891144 (Ejegg) Hi @CCogdill_WMF, # Looks like the param is indeed case s... [18:42:26] (CR) Ejegg: KVStore: Wrap accesses to LocalStorage in try/catch blocks (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/259986 (https://phabricator.wikimedia.org/T121738) (owner: AndyRussG) [18:44:58] K4-713: ejegg: cwd: XenoRyet: popcorn in #wikimedia-perf BTW [18:45:26] I still crack up at the abbrev name [18:45:41] * K4-713 makes holes [18:46:36] awight: better than the analytics chan [18:46:59] Your source for all chibi numbers. [18:47:32] ejegg: wikimedia-anal? [18:47:45] AndyRussG: I will go for the backscroll, but I'm going to trust you all to do the actual things. :) [18:47:55] awight: Noooooope. [18:47:56] +1 ^ [18:48:08] :p [18:48:13] Wat? this isn't just a giant multiplayer game? [18:48:29] AndyRussG: I haven't ruled that out. [18:48:46] But... I'm leveling up in something entirely different today. [18:53:06] AndyRussG: I know this isn't quite our job, but do you happen to know what meganhernandez is projecting for $$ raised by mobile banners? [18:54:04] awight: no idea I'm afraid [18:54:08] meganhernandez: Or if you have that info on hand? I'd like to know as background for triaging the mobile impressions issue. [18:54:35] awight: side note: do you know what happened to Ellery's repo for his datachewing code? I couldn't find it, apparently he's going on vacation soon [18:55:00] AndyRussG: https://github.com/ewulczyn/wmf/ [19:00:32] awight: R u sure his FR code is still there? it somehow looked like he moved it, maybe reorganized the dirs, dunno [19:02:06] hey awight AndyRussG i am in a couple meetings right now, but ellery will be able to help fill you in [19:02:18] i talked to him this morning. he’s on his way to the office now [19:02:43] definitely keep him & mikhail in the loop on anything you find & any questions you have [19:03:17] meganhernandez: OK, thanks! can we met with mikhail too then? [19:04:15] yep do you have his email? [19:04:34] i’m not sure his irc [19:04:52] meganhernandez: Oh hi! I just explained the potential triage scenario to Lisa. [19:04:58] meganhernandez: yes I cc'ed him on the thread [19:25:55] Fundraising-Backlog, Wikimedia-Fundraising, MediaWiki-extensions-CentralNotice: Consider a fallback banner for when geolocation fails - https://phabricator.wikimedia.org/T121904#1891311 (awight) NEW [19:56:02] AndyRussG: It looks like ewulczyn scrubbed that stuff we asked him to. Plus a bit. We'll have to get the private repo from him now... Which crunching were you looking for? [19:56:57] awight: I didn't dig enough to know specifically, just noticed some stuff had moved, and I wanted to maybe use or build on some of his code... [19:57:59] There was one thing in there which we needed to make private, and I see that it's missing now. [19:58:19] There are a bunch of empty commits as well... Not sure how he did that. [20:16:09] awight: was the private stuff important for our work just now? [20:16:20] I don't know! [20:33:45] Fundraising Sprint William Shatner, Fundraising Sprint X-Ray Spex, Fundraising Sprint Yo La Tengo, Fundraising Sprint Zapp, and 2 others: Track email clickthroughs on donate wiki - https://phabricator.wikimedia.org/T114010#1891466 (CCogdill_WMF) Ah, okay, that email went out at 21:00 UTC on 12/16,... [22:25:23] Fundraising-Backlog: Amazon: duplicate transaction - only 1 reached Civi - https://phabricator.wikimedia.org/T121920#1891714 (MBeat33) NEW [22:41:53] Fundraising Tech Backlog, Traffic, operations, Patch-For-Review: Switch Varnish's GeoIP code to libmaxminddb/GeoIP2 - https://phabricator.wikimedia.org/T99226#1891760 (ori) [22:42:30] Fundraising Sprint Zapp, Unplanned-Sprint-Work: Firefox SPDY is buggy and is causing geoip lookup errors for IPv6 users - https://phabricator.wikimedia.org/T121922#1891764 (AndyRussG) NEW [22:46:17] Fundraising Sprint Zapp, Unplanned-Sprint-Work: Firefox SPDY is buggy and is causing geoip lookup errors for IPv6 users - https://phabricator.wikimedia.org/T121922#1891784 (AndyRussG) [22:47:18] Fundraising Sprint Zapp, Traffic, Unplanned-Sprint-Work, operations: Firefox SPDY is buggy and is causing geoip lookup errors for IPv6 users - https://phabricator.wikimedia.org/T121922#1891797 (faidon) p:Triage>High [22:49:26] Fundraising Sprint Zapp, Traffic, Unplanned-Sprint-Work, operations: Firefox SPDY is buggy and is causing geoip lookup errors for IPv6 users - https://phabricator.wikimedia.org/T121922#1891801 (faidon) This looks like a Firefox bug and it seems to affect fundraising right now. It doesn't appear to... [22:52:16] Fundraising Sprint Enya, Fundraising Sprint Flaming Lips, Fundraising Tech Backlog, Fundraising-Backlog, and 2 others: [2 hours] BUG: Donation link geolocation not working consistently - https://phabricator.wikimedia.org/T87677#1891815 (ori) I don't know the workflow of the Fundraising team very... [22:52:24] Fundraising Tech Backlog, Traffic, operations, Patch-For-Review: Switch Varnish's GeoIP code to libmaxminddb/GeoIP2 - https://phabricator.wikimedia.org/T99226#1891818 (Krinkle) [23:02:26] Fundraising Sprint Zapp, MediaWiki-extensions-CentralNotice, Unplanned-Sprint-Work: No banner showing for Krinkle - https://phabricator.wikimedia.org/T121926#1891835 (AndyRussG) [23:02:57] Fundraising Sprint Zapp, MediaWiki-extensions-CentralNotice, Unplanned-Sprint-Work: No banner showing for Krinkle - https://phabricator.wikimedia.org/T121926#1891837 (Krinkle) [23:08:51] Fundraising-Backlog, Wikimedia-Fundraising, MediaWiki-extensions-DonationInterface: Donors need an option to pay from another country - https://phabricator.wikimedia.org/T96047#1891843 (awight) [23:13:46] Fundraising-Backlog, Wikimedia-Fundraising, MediaWiki-extensions-DonationInterface: Donors need an option to pay from another country - https://phabricator.wikimedia.org/T96047#1891867 (ori) >>! In T96047#1207246, @atgo wrote: > Hi @awight... why do we want to do this? I'm concerned that we're crafti... [23:30:54] Is master of DonationInterface deployed with an older version of MW? [23:36:05] Reedy: yes. Anything I should know? [23:36:13] I was trying to get things in sync [23:36:42] I'm happy to do a Friday deployment if you think it's an... emergency [23:36:43] Noticed you were pinned against an old version of monolog and zordius vs those use in master of mw core [23:36:53] Oh no, it's not an emergency, hahah [23:37:18] but just running composer update gives a lovely error for The .git directory is missing from /var/www/wiki/mediawiki/extensions/DonationInterface/vendor/coderkungfu/php-queue, see https://getcomposer.org/commit-deps for more informati [23:37:18] on [23:37:23] https://phabricator.wikimedia.org/T121932 [23:37:31] hehe ok well we can do this next week if that works. [23:37:34] We're using fundraising/REL1_25 [23:38:04] (I'm trying to find where we merged last) [23:38:32] Our last MFT was 4e676f750cf1002f45d9fcda82d0f983f9836855 [23:38:40] off of REL1_25 [23:38:51] Fundraising-Backlog, Wikimedia-Fundraising, MediaWiki-extensions-CentralNotice: Consider a fallback banner for when geolocation fails - https://phabricator.wikimedia.org/T121904#1891914 (Pcoombe) Well, couldn't you just do this currently with a non geolocated campaign at a lower priority? I'm not su... [23:39:09] I guess it puts it in a weird place [23:40:00] The fact it breaks is one issue [23:40:15] Though, I presume updating other libraries is a little bit of a grey area [23:41:38] I wonder how that works in production [23:41:46] composer-merge-plugin works? [23:42:23] No, we do a terrible thing (which I thought we copied from wmf production mw) where we have a deployment branch with vendor/ as a submodule [23:44:01] oh [23:44:05] I clone all the things [23:44:25] That'll explain why it appears in my clones [23:44:45] Fundraising-Backlog, MediaWiki-extensions-DonationInterface: composer broken on DonationInterface vendor repo - https://phabricator.wikimedia.org/T121932#1891926 (awight) [23:44:58] I responsed there ^, pretty sure I've dealt with that before [23:45:30] but--is this something other people are going to run into, or are you just doing cleanup duties on your dev box? [23:45:44] I mean, I want to fix it either way, but at a different priority. [23:45:55] I'm just updating things in core etc [23:45:59] And was trying to keep things in sync [23:46:06] I've got a feeling [23:46:06] "coderkungfu/php-queue": "dev-master", [23:46:11] confuses things [23:46:19] as it'll be looking on packagist [23:47:30] I think that's the correct syntax, unfortunately [23:47:51] there's a "repositories" clause further down [23:48:15] try rm -rf the vendor directory and updating again... [23:49:43] Mmm. That works [23:52:29] So there's obviously something kooky [23:53:30] awight: I wonder if it's worth an upstream bug [23:53:33] Fundraising Sprint Zapp, Fundraising-Backlog, Unplanned-Sprint-Work: Verify geoloaction is working correctly and not affecting FR campaigns - https://phabricator.wikimedia.org/T121937#1891956 (AndyRussG) NEW [23:53:52] Fundraising Sprint Zapp, Fundraising-Backlog, Traffic, Unplanned-Sprint-Work, operations: Firefox SPDY is buggy and is causing geoip lookup errors for IPv6 users - https://phabricator.wikimedia.org/T121922#1891963 (AndyRussG) [23:54:01] I presume the error will only occur if there's changes in the repo since the last composer update [23:54:39] Fundraising Sprint Zapp, Fundraising-Backlog, Traffic, Unplanned-Sprint-Work, operations: Firefox SPDY is buggy and is causing geoip lookup errors for IPv6 users - https://phabricator.wikimedia.org/T121922#1891764 (AndyRussG) [23:54:41] Fundraising Sprint Zapp, Fundraising-Backlog, Unplanned-Sprint-Work: Verify geoloaction is working correctly and not affecting FR campaigns - https://phabricator.wikimedia.org/T121937#1891964 (AndyRussG) [23:55:23] awight: Though, is there any reason we can't just use the upstream repo, and specify a commit? [23:55:37] It still seems to be a composer bug, I'm finding a lot of other projects where they hit this issue, and either rm-rf'd the directory or switched to using a tagged version. [23:55:58] Well... we've forked it and only successfully upstreamed about half the patches. [23:56:07] Yeah, I saw that now [23:56:20] I wonder if it's already a reported issue on github [23:56:37] Fundraising Sprint Zapp, Fundraising-Backlog, Unplanned-Sprint-Work: Verify geolocation is working correctly and not affecting FR campaigns - https://phabricator.wikimedia.org/T121937#1891969 (awight) [23:57:13] The error message in essence makes sense, the git repo won't exist because different people updated it etc [23:58:07] Fundraising Sprint Zapp, MediaWiki-extensions-CentralNotice, Unplanned-Sprint-Work: No banner showing for Krinkle - https://phabricator.wikimedia.org/T121926#1891972 (ori) [23:58:09] Fundraising Tech Backlog, Traffic, operations, Patch-For-Review: Switch Varnish's GeoIP code to libmaxminddb/GeoIP2 - https://phabricator.wikimedia.org/T99226#1891973 (ori) [23:58:11] Fundraising Sprint Zapp, Fundraising-Backlog, Unplanned-Sprint-Work: Verify geolocation is working correctly and not affecting FR campaigns - https://phabricator.wikimedia.org/T121937#1891971 (ori) [23:58:13] Fundraising-Backlog, Wikimedia-Fundraising, MediaWiki-extensions-DonationInterface: Donors need an option to pay from another country - https://phabricator.wikimedia.org/T96047#1891974 (ori) [23:58:27] Fundraising Sprint Zapp, Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Unplanned-Sprint-Work: Fix GeoIP lookup for IPv6 - https://phabricator.wikimedia.org/T121938#1891975 (awight) NEW [23:58:40] Fundraising Sprint Zapp, Fundraising-Backlog, Unplanned-Sprint-Work, Tracking: [Tracking] Verify geolocation is working correctly and not affecting FR campaigns - https://phabricator.wikimedia.org/T121937#1891981 (ori) [23:59:06] Fundraising-Backlog, Wikimedia-Fundraising: PayPal donation link sometimes unresponsive - https://phabricator.wikimedia.org/T120995#1891984 (MBeat33) #191928 using Safari 9.0.2 on OS X 10.11.2: "Whenever the popup donation screen comes up on Wikipedia, I try to click the PayPal button, or the Credit Car...