[16:47:57] <mobrovac>	 bearND: ping?
[17:18:32] <dbrant>	 niedzielski: mdholloway: o/  mind a quick hangout?
[17:18:50] <mdholloway>	 sure, i'll be there shortly
[17:20:49] <niedzielski>	 sure
[17:21:18] <bearND>	 mobrovac: Hi
[17:31:39] <mobrovac>	 bearND: regarding the deployment, what's the list of changes that you'd need to deploy?
[17:32:37] <bearND>	 I was hoping to deploy https://gerrit.wikimedia.org/r/#/c/332423 but that still needs a +2 first
[17:32:41] <bearND>	 mobrovac: ^
[17:33:44] <bearND>	 mobrovac: that one is to fix an issue visible in the Android app introduced by a Parsoid change
[17:39:36] <mobrovac>	 looking
[17:41:41] <mobrovac>	 bearND: lgtm, would you be free to do the deploy soon-ish (in the next hour or so) ?
[17:42:14] <bearND>	 mobrovac: yes, I can do it as soon as it's merged
[17:43:02] <mobrovac>	 cool
[17:43:12] <bearND>	 mobrovac: as long as it's done withing the next 45 minutes
[17:43:15] <bearND>	 within
[17:43:15] <mobrovac>	 mdholloway|afk: mind give another look at https://gerrit.wikimedia.org/r/#/c/332423/ ?
[17:43:18] <mobrovac>	 k
[17:55:21] <mdholloway|afk>	 bearND: mobrovac: looking quickly now
[17:55:35] <mobrovac>	 thnx
[17:56:52] <bearND>	 mdholloway|afk: thanks. I just pushed a small update to address niedzielski 's comments
[18:10:47] <mdholloway|afk>	 bearND: it doesn't seem to be working on today's enwiki featured article, 'Hope_(painting)'
[18:11:00] <mdholloway|afk>	 bearND: it works on Barack_Obama, thouhg
[18:11:02] <mdholloway|afk>	 though
[18:24:32] <bearND>	 mdholloway|afk: Ok, I found the culprit. I need to replace all spaces with _ for the CSS selector.
[18:25:51] <bearND>	 mobrovac: Pchelolo : It's too late to fix this, add tests, get it reviewed and push through Gerrit several times to get it deployed before my next meeting in 5 minutes. So, I'll let you do the node 6 update first.
[20:30:45] <mdholloway>	 niedzielski: re: https://gerrit.wikimedia.org/r/#/c/317286/4/app/src/main/java/org/wikipedia/language/LangLinksClient.java, were you envisioning the helper methods going right in same Callback class with success() and failure() ?
[20:31:05] <mdholloway>	 niedzielski: that wasn't making sense to me yesterday but it's starting to today :)
[20:31:57] <niedzielski>	 👍
[20:32:15] <mdholloway>	 niedzielski: cool, update incoming shortly
[20:32:19] <mdholloway>	 niedzielski: thanks!
[20:32:53] <niedzielski>	 sounds good!
[21:53:13] <mdholloway>	 niedzielski: good catch about the possible null-unmarshalling list items in the page coordinates! (https://gerrit.wikimedia.org/r/#/c/317292/7/app/src/main/java/org/wikipedia/server/mwapi/MwApiResponsePage.java)
[21:53:34] <mdholloway>	 niedzielski: i'd assumed they'd just not be added to the list but in fact they are added as null objects
[21:54:17] <niedzielski>	 geez, good to know. i wasn't really sure and then i later saw you had a client test case for a similar scenario
[21:54:19] <mdholloway>	 niedzielski: what i'd intended is for them not to be added but it looks like that'll take some extra logic.  does that seem like a sane thing for the type adapter to take care of, or should we leave it to consumers to de-null their lists?
[21:55:24] <niedzielski>	 i would de-null at the source unless nulls have meaning. it's a little unusual to pass around lists containing nulls in my opinion
[21:56:00] <niedzielski>	 i think one way to de-null the list would be ArrayUtils.removeAllOccurences(list, null)
[22:10:35] <mdholloway>	 is anyone else seeing their google results entirely in the form of cards?
[22:10:43] <mdholloway>	 i'm... not into it
[22:12:38] <mdholloway>	 niedzielski: the trouble is i'm not seeing any way of knowing in the context of the type adapter that the object we're deserializing is going to go into a List
[22:13:03] <mdholloway>	 and the List itself doesn't appear to pass through public T read(JsonReader in)
[22:13:20] <mdholloway>	 at any point
[22:13:21] <niedzielski>	 google on desktop?
[22:13:25] <mdholloway>	 niedzielski: yep
[22:13:39] <niedzielski>	 hm, no to the cards ui
[22:14:06] <niedzielski>	 just a sec on the adapter sturf
[22:15:38] <mdholloway>	 https://usercontent.irccloud-cdn.com/file/13Hra578/Screen%20Shot%202017-01-19%20at%205.13.38%20PM.png
[22:16:55] <niedzielski>	 ha, yeah i'm still on classic
[22:25:18] <niedzielski>	 mdholloway: i think you'd have to subclass ArrayTypeAdapter but i'm looking for a little more detail
[22:40:51] <mdholloway>	 niedzielski: given that we only ever use the first set of coordinates afaik, i guess we could dodge the problem by defining a custom type adapter that just grabs and returns the first set of coords as a Coordinates object and not even bothering with a List
[22:43:29] <niedzielski>	 mdholloway: yet another option would be an additional collection annotation @RequiredElement but that'd be a little bit of work. hm, maybe you could just de-null in MwApiResponsePage.coordinates() and add a todo
[22:45:03] <mdholloway>	 yeah, i can probably live with a todo
[22:45:29] <mdholloway>	 i was also looking a little bit into standard List implementations in the JDK that refuse to accept nulls, but not much luck there either
[22:51:14] <dbrant>	 mdholloway: I just added a description to an article, and it took over a minute to propagate :[
[22:51:34] <dbrant>	 ^ cc Pchelolo
[22:52:06] <mdholloway>	 dbrant: (╯°□°）╯︵ ┻━┻
[22:52:15] <Pchelolo>	 dbrant: we're doing node 6 upgrade now, and having some problems
[22:52:16] <Pchelolo>	 so CP is down
[22:52:26] <Pchelolo>	 will get it back up in a moment
[22:52:29] <dbrant>	 aha! ok then, thanks