[00:12:59] <HaeB>	 bd808: so how persistent is mw.user.sessionId() ?
[00:13:28] <bd808>	 it's a session scoped cookie, so sticks until browser cloases
[00:13:53] <HaeB>	 i see
[00:14:16] <bd808>	 the current implementation in MF is not session scoped and really is a durable tracking token which is not cool
[00:15:11] <HaeB>	 yes, we discussed this ;) and it's indeed not needed to be permanent for the data analysis questions at hand
[00:16:25] <HaeB>	 ..."until browser closes" should be fine for these (but i think we still need to add another event to the schema - jdlrobson would you have a few minutes to chat about this now?)
[00:16:56] <bd808>	 the patch I have up now relies on a proposed patch for core from ori. It would use the browser sessionStorage system which is also browser window/session scoped
[00:17:42] <bd808>	 But when Timo pointed out that this same functionality is already in mw.user that seemed like the right fix
[00:19:45] <bd808>	 technically the session scoped cookie is a bit stickier than sessionStorage in some browsers
[00:20:26] <bd808>	 sessionStorage can be scoped to a tab exclusively in some versions of Firefox (and maybe other browsers)
[00:59:38] <bmansurov>	 o/
[01:17:10] <jdlrobson>	 hey bd808 sorry only just escapedm eetings
[01:17:41] <bd808>	 jdlrobson: no worries. I figured you would see the ping eventually
[01:18:12] <jdlrobson>	 I think using mw.user.sessionId() is fine
[01:18:17] <jdlrobson>	 i didn't know it existed
[01:18:30] <bd808>	 yeah, me neither :)
[01:18:45] <jdlrobson>	 and it seems i can just merge your patch when that's done
[01:18:46] <bd808>	 I'll amend to just proxy that then
[01:18:50] <jdlrobson>	 since the issue can be fixed elsewhere :)
[01:24:50] <bd808>	 we could maybe followup up with replacing that getSessionId call everywhere with direct usage of mw.user.sessionId to tidy things up
[01:31:22] <jdlrobson>	 bd808: guess js doc header needs changing 
[01:31:47] * bd808 looks
[01:33:14] <jdlrobson>	 bmansurov: hey - so deployment of RelatedArticles - we need to schedule a day, find a deployer and get it in the calendar. Are you on that?
[01:33:31] <jdlrobson>	 i pinged Greg earlier and he said Monday or Tuesday next week or week after should be fine
[01:33:34] <bmansurov>	 jdlrobson: hi
[01:33:44] <bmansurov>	 jdlrobson: yes, I can do that.
[01:33:52] <jdlrobson>	 thanks bmansurov 
[01:33:59] <jdlrobson>	 I expect we'll move it over to next sprint
[01:34:08] <bmansurov>	 jdlrobson: what about the security review? done already?
[01:34:25] <jdlrobson>	 bmansurov: i'm not sure what's going on there - need to sync up with Sam - but we should work on the assumption it will be done
[01:34:37] <bmansurov>	 ok
[01:58:21] <jdlrobson>	 bmansurov_away: can you chat?
[01:58:39] <jdlrobson>	 So with your latest patch with $wgRelatedArticlesShowReadMore = false I see the related articles in the sidebar
[02:00:11] <jdlrobson>	 but with $wgRelatedArticlesShowReadMore = true  i dont see read more
[02:00:33] <jdlrobson>	 its neither in side bar nor bottom of page. (I think it should actually show both in sidebar and footeR)
[02:00:33] <bmansurov>	 jdlrobson: yes
[02:00:51] <bmansurov>	 jdlrobson: you need to enable it in beta features
[02:00:57] <jdlrobson>	 bmansurov: it is enabled in beta features
[02:01:08] <bmansurov>	 jdlrobson: are you testing it locally?
[02:01:12] <bmansurov>	 can you share a url?
[02:01:33] <jdlrobson>	 oh wait. it's just very slow but is working
[02:01:40] <bmansurov>	 ok
[02:01:43] <jdlrobson>	 it does suppress the links in the navigation menu though
[02:01:45] <jdlrobson>	 which is bad
[02:01:59] <bmansurov>	 since both show the same information
[02:02:00] <jdlrobson>	 since that's a change in behaviour for Wikivoyage for users not using readmore if the beta feature is enabled
[02:02:26] <bmansurov>	 then sam's patch will solve this issue i think
[02:02:49] <jdlrobson>	 Yes but your patch would leave it in a broken state - which was why i was hoping you could combine ideas :)
[02:03:13] <jdlrobson>	 given its not deployed yet im happy to merge your patch as is provided we ensure Sam's patch gets merge asap
[02:03:24] <jdlrobson>	 I'd have to cut open a new bug though :)
[02:03:34] <bmansurov>	 ok
[02:03:37] <bmansurov>	 i'll review sam's patch
[02:03:40] <bmansurov>	 if you can merge mine
[02:03:57] <jdlrobson>	 I've reviewed Sam's it has issues
[02:04:23] <bmansurov>	 the code is currently broken anyway, my patch fixes some of the issues
[03:33:06] <codezee>	 jdlrobson: hi, my exams are over, and I'll be trying to clear the pagebanner board, Meanwhile if you have intermediate tasks needing help. feel free to add me, I'd be happy to learn along
[10:24:05] <bmansurov>	 phuedx: hello. i ran out of things to do. do you want me to take over one of you patches?
[10:24:15] <phuedx>	 lol
[10:24:28] <bmansurov>	 ;)
[10:28:35] <thedj>	 https://en.wikipedia.org/wiki/MediaWiki_talk:Common.css#Responsive_image_positioning
[10:28:51] <thedj>	 for those interested
[10:30:18] <phuedx>	 thedj: neato!
[10:31:35] <thedj>	 later I intend to do the same for infoboxes
[10:33:09] <thedj>	 I also recently made the tabs in responsive mode of vector behave:
[10:33:10] <thedj>	 https://phabricator.wikimedia.org/T106463
[10:33:20] <thedj>	 see the last image
[10:36:03] <thedj>	 i think we should investigate redoing Vector with flex...
[10:36:16] <thedj>	 would be an intersting experiment
[10:43:25] <d3r1ck>	 hey
[10:45:46] <phuedx>	 thedj: i can't disagree with that idea, but surely the scope is /huge/
[10:46:02] <phuedx>	 needs to be broken down into manageable chunks
[10:47:23] <phuedx>	 bmansurov: here's an idea: browser tests for relatedarticles?
[10:47:34] <phuedx>	 including opting in to the beta feature
[10:48:46] <bmansurov>	 phuedx: sounds good. i remembered i had to do something else too.
[10:49:49] <thedj>	 phuedx: we can always investigate. Just make the code, deploy it on a test instance.
[10:50:00] <thedj>	 then see "what is needed to make this a beta or a mergeable"
[10:52:19] <phuedx>	 bmansurov: sure you did ;)
[10:52:37] <phuedx>	 thedj: true
[12:04:28] <bmansurov>	 will be back later
[12:42:53] <phuedx>	 joakino: yt?
[12:43:20] <joakino>	 yea
[12:43:36] <joakino>	 phuedx: ^
[12:44:18] <phuedx>	 which one of us should merge loot-ui#18?
[12:44:21] <phuedx>	 it lgtm
[12:57:01] <joakino>	 phuedx: are you ok with my last commits?
[12:57:29] <phuedx>	 joakino: no, i hate them, they're terrible, which is why i asked you who's responsible for merging it ;) ;P
[12:57:32] <phuedx>	 they're good
[12:58:01] <joakino>	 phuedx: merged, rebase your pr on top of master
[12:58:15] <phuedx>	 shall do
[12:58:25] <joakino>	 phuedx: have a look at the commits with layout less since that's changed on the parent PR (to be padding based & stuff
[12:58:30] <joakino>	 idk i left a ton of comments XD
[13:37:55] <joakino>	 every day I find a great one haha http://media1.giphy.com/media/VanFQpRWa6Xh6/giphy.gif
[13:38:35] <joakino>	 out for dog-lunch-siesta
[13:39:45] <phuedx>	 joakino: WAT
[13:47:33] <phuedx>	 breaking for lunch
[15:22:27] <phuedx>	 back
[15:56:16] <joakino>	 i'm back
[15:56:17] <joakino>	 no siesta today
[16:21:04] <joakino>	 netsplits everywhere
[16:23:00] <dbrant>	 joakino: did the screen mirroring tool work out?
[16:23:26] <joakino>	 i didn't get around to testing it dbrant
[17:20:40] <niedzielski>	 mdholloway dbrant: hello! if you have a little time, a review would be much appreciated on https://gerrit.wikimedia.org/r/#/c/255057/. it's not critical for the release since it only affects 10% of beta users but it would help me manage some patch dependency stacks
[17:21:51] <dbrant>	 niedzielski: but it's dependent on the native toolbar patch...
[17:22:20] <niedzielski>	 dbrant: oh nuts. you're right :|
[17:22:31] <niedzielski>	 nevermind :)
[17:39:34] <dr0ptp4kt_webcha>	 yo kristenlans you there?
[17:39:46] <kristenlans>	 dr0ptp4kt_webcha: yes
[17:40:06] <kristenlans>	 dr0ptp4kt_webcha: am I missing a meeting?
[17:41:50] <kristenlans>	 dr0ptp4kt_webcha: ah I see your email
[17:48:43] <mbinder>	 Dbrant Internet guy here early, might miss standup
[17:49:10] <dbrant>	 mbinder: no worries, we'll try to manage
[18:01:57] <joakino>	 dr0ptp4kt_: dr0ptp4kt_webcha the dashboard is totally public https://i.imgur.com/Hg7zaKz.png not sure why it doesn't work
[18:09:34] <mbinder>	 dbrant: brave soldiers 
[18:58:50] <dbrant>	 niedzielski: needs manual rebase: https://gerrit.wikimedia.org/r/255157
[18:59:12] <niedzielski>	 dbrant: thanks, will do
[19:19:56] <niedzielski>	 dbrant mdholloway: ok, i think everything is merged up. we ready to start a beta?
[19:20:54] <dbrant>	 niedzielski: i believe so!
[20:03:07] <mbinder>	 dbrant: joining grooming? optional but yer the po :)
[21:01:24] <HaeB>	 dbrant: have you had a chance to look at https://phabricator.wikimedia.org/T119664 ? 
[21:01:55] <HaeB>	 dbrant: hopefully mysql already did most of the work there, but JonKatz and i thought that you folks are in the best position to verify which version of the production app sends the data to which table
[21:03:50] <dbrant>	 HaeB: So, the "latest" version of the schema is pretty easy, since that only corresponds to the latest release (2.1.134)...
[21:06:07] <dbrant>	 HaeB: the next-to-latest version of the schema corresponds to production releases as early as 2015-03-23...
[21:07:18] <HaeB>	 dbrant: ok cool, that confirms the first row at least (disregarding beta/fdroid/amazon )...
[21:08:46] <HaeB>	 ...and yes, 2015-03-23 is the earliest production date in the second row, afaics
[21:09:36] <dbrant>	 and I can confirm that in the code.
[21:11:25] <HaeB>	 cool, if you can vet this, that migth already be enough for the present purposes (i.e. to know that i can query those tables, restricted to production UAs, to compare these releses) 
[21:12:07] <dbrant>	 HaeB: the earliest production release for the third row also looks right (2014-11-03)...
[21:13:06] <dbrant>	 HaeB: yep, i can send you the exact git revisions.
[21:13:23] <HaeB>	 that would be great
[21:29:05] <niedzielski>	 mdholloway dbrant: i'm not sure if this is something weird in my setup but i can't get link previews to work with the content service master. it seems to work fine with the prod content service. i was having the opposite problem last week.
[21:32:28] <mdholloway-ii>	 niedzielski: yeah, we still only have the /page/mobile-summary route locally, i think bernd said somewhere he was planning to patch this when he got back
[21:33:29] <mdholloway-ii>	 niedzielski: the /page/summary route doesn't actually served by the mobile content service, but rather directly from RESTBase
[21:33:50] <mdholloway-ii>	 s/doesn't/isn't (i can't into english today)
[21:33:53] <niedzielski>	 mdholloway-ii dbrant: i'm also seeing two other issues when using the content service. 1) i can only read articles in the english language. i think this is a known limitation and is only occurring because i have force RB on (it doesn't fall back to MW). 2) if i change the article language to something arabic, i actually get a 404
[21:34:23] <niedzielski>	 mdholloway-ii dbrant: i think this is all expected but thought i'd mention it
[21:35:08] <mdholloway-ii>	 niedzielski: yep, known issue.  we're limiting it to english until the services guys have worked out how they're going to handle things like simplified vs. traditional chinese 
[21:37:02] <niedzielski>	 mdholloway-ii dbrant: it's just weird that a language like catala loads in english but arabic is a 404
[21:37:12] <mdholloway-ii>	 niedzielski: actually, the arabic thing isn't expected, yeah
[21:37:20] <bearND>	 mdholloway-ii: hmmm, that's news to me about limiting to only English. I thought it would just skip RB with zh lang.
[21:37:22] <mdholloway-ii>	 niedzielski: mind phabbing it?  
[21:38:26] <niedzielski>	 bearND: maybe i have my endpoint setup wrong? i've hardcoded en.m.wikipedia.org into it
[21:38:29] <mdholloway-ii>	 bearND: actually, you're right, i stand corrected.  i'm thinking back to a much earlier discussion where we talked about limiting to english.  
[21:38:32] <niedzielski>	 mdholloway: sure
[21:44:35] <mdholloway-ii>	 bearND: since you're around (aren't you supposed to be on leave? ;) ) you may have noticed on the deployments calendar that there's been a moratorium on normal deployments since last week.  do you want to try to get an exception to deploy the last couple of updates this week, or just wait until normal deploys are back on monday? 
[21:45:36] <bearND>	 mdholloway-ii: Monday is fine
[21:45:51] <mdholloway>	 bearND: sounds good
[21:49:41] <mdholloway>	 niedzielski: non-english articles (including arabic) seem to be working fine for me from prod
[21:52:07] <niedzielski>	 mdholloway dbrant: i put in a patch here for a potential regression: https://gerrit.wikimedia.org/r/256578 . i don't have repro steps but it appears to be a regression according to ha
[21:58:46] <niedzielski>	 mdholloway: weird. i https://en.m.wikipedia.org/api/rest_v1 with an app language of english. i search for and go to the apple article and select an arabic langauge and get the 404.
[21:59:10] <dbrant>	 niedzielski: looks like you clicked on a nonexistent page (but how was that possible if you had RB disabled?)... anyway, I'll merge once checkstyle is fixed.
[22:00:26] <niedzielski>	 dbrant: it must be a caching issue. do we want this in the release or can it wait till later?
[22:01:04] <dbrant>	 niedzielski: if you've already got the ball rolling, then it can wait...
[22:02:06] <niedzielski>	 dbrant: yeah, so far that's the only real issue i've seen. let's circle back once i'm done
[22:02:15] <dbrant>	 sure
[22:19:19] <niedzielski>	 dbrant mdholloway: please take a peek at the release notes when you can :)
[22:21:56] <mutante>	 hello mobile team, when cleaning up Apache config in a different matter (old redirects for stuff like www.de.wikipedia.org that dont exist anymore) we noticed that we have a "www.m." (as opposed to languages), but only for wikipedia.org and not for any other projects. It would be nice to know if we could a) delete www.m.wikipedia.org (because it is maybe no different from the "desktop" URL)  or  b) it should actually be added for other project
[22:22:24] <mutante>	 this might somehow be related to the "move portals to gerrit" work
[22:23:02] <niedzielski>	 dbrant mdholloway: everything else seems to be working properly
[22:23:06] <mutante>	 if this was a wiki it would be about mobile frontend extension, but no clue with portal pages
[22:25:29] <niedzielski>	 mutante dbrant mdholloway: i don't know of any place where android is using m.wikipedia.org
[22:28:26] <mutante>	 niedzielski: thanks! context is this change by Reedy where he suggested to remove a rewrite rule, that is like [a-z].m.wikipedia.org and none of those exist in DNS for languages.. just the "www" thing  https://gerrit.wikimedia.org/r/#/c/256441/
[22:29:01] <mutante>	 eh, sorry: URLs like: www.de.wikipedia.org
[22:29:43] <niedzielski>	 mutante: but not URLs like ru.m.wikipedia.org, right?
[22:29:51] <Reedy>	 nope
[22:29:59] <Reedy>	 literally just www.m.wikipedia.org
[22:30:40] <niedzielski>	 Reedy mutante: i don't know of any spot that would affect android. /cc mdholloway dbrant
[22:30:54] <mutante>	 eh, yea, it's too confusing, i should just paste:)
[22:30:58] <mutante>	     RewriteCond %{HTTP_HOST} ^www\.([a-z-]+)\.wikipedia\.org$
[22:31:00] <mutante>	 this
[22:31:55] <mutante>	 "www.en.wikipedia.org" "www.de.wikipedia.org" .. none of them exist.. but  "www.m.wikipedia.org" does
[22:32:11] <mutante>	 and that is a special case only for WP
[22:36:06] <niedzielski>	 mutante: yeah i don't think we point to www.m.wikipedia.org anywhere. everything's either lang.m.wikipedia.org, lang.wikipedia.org, or www.wikipedia.org AFAIK
[22:36:54] <mutante>	 niedzielski: thanks!
[22:39:19] <niedzielski>	 np :)
[22:39:49] <mutante>	 can i paste that on gerrit or something? i'll upload a change to delete it from DNS then for later i think
[22:40:06] <mutante>	 can also add more reviewers 
[22:43:04] <niedzielski>	 mutante: not sure if you were referring to my comment but feel free to
[22:45:51] <niedzielski>	 dbrant mdholloway: everything's good on my end for a release except that npe. from the ha perspective, it's a regression. from the code perspective, i don't think it's likely there's been a user accessible change to introduce it.
[22:46:19] <mutante>	 niedzielski: yes, i did. thanks
[22:50:31] <mutante>	 Reedy: niedzielski: if i got it right then 0.00027% of all hits are www.m.
[22:50:56] <mdholloway>	 niedzielski: ha=hockeyapp?
[22:51:35] <niedzielski>	 mdholloway: right :)
[22:59:13] <mdholloway>	 niedzielski: it troubles me not knowing where this npe is coming from all of a sudden, but i'm happy to merge your patch once the checkstyle thing is fixed, i think dbrant said the same at some point.
[22:59:44] <mdholloway>	 niedzielski: if we're not getting summary text under some circumstances we should be, hopefully that'll become apparent soon.
[23:00:06] <mdholloway>	 niedzielski: i haven't had any trouble with the new /page/summary route.
[23:01:17] <mdholloway>	 niedzielski: release notes look good to me, btw
[23:04:54] <niedzielski>	 mdholloway: well, on the other hand, the patch is pretty low risk. i can merge it and just do a quick test so we feel more confident around content service abnormalities
[23:05:55] <mdholloway>	 niedzielski: agreed.  no reason not to merge.
[23:06:38] <niedzielski>	 mdholloway: ok cool. i don't think dbrant|mtg would be opposed. would you mind reviewing the patch and +2ing?
[23:07:40] <mdholloway>	 niedzielski: sure, there's just the checkstyle thing that i think is blocking it.
[23:08:46] <mdholloway>	 niedzielski: :app:checkstyle[ant:checkstyle] /mnt/jenkins-workspace/workspace/apps-android-wikipedia-test/app/src/main/java/org/wikipedia/page/PageTitle.java:127:12: error: '@Nullable' annotation modifier does not precede non-annotation modifiers.
[23:09:23] <niedzielski>	 mdholloway: sorry fixed
[23:33:36] <mdholloway>	 niedzielski: are we all set, then, for the beta release?
[23:34:02] <niedzielski>	 mdholloway: i thought so until 30 seconds ago. i'm investigating some odd behavior. will follow up shortly
[23:34:41] <mdholloway>	 niedzielski: dang.
[23:37:14] <niedzielski>	 mdholloway: hm, i can't repro. i just a very weird issue i've never seen before. i'm testing on my nexus 6p with app language in german and system language in english. i did a search for a previously searched item and started scrolling while it loaded results. the loading seemed a bit odd. i tried a new query, "dog", and it appeared to be an infini
[23:37:15] <niedzielski>	 te search loop :|
[23:37:58] <niedzielski>	 mdholloway|brb: it's like when i scroll it queues up a ton of queries or something
[23:38:53] <niedzielski>	 mdholloway|brb: hm, there we go. yeah, just gotta get a mighty scroll in while it's loading that first set. repros best by selecting a previous query
[23:39:05] <mdholloway|brb>	 niedzielski: i'll see if i can repro
[23:39:07] <niedzielski>	 mdholloway|brb: it appears to eventually stop
[23:40:18] <niedzielski>	 mdholloway|brb dbrant: here's more concise steps (app language english, system language english): 1) tap a previous search (neptune in my case). 2) fling up very quickly while the result set is still loading (green progress bar). 3) keep flinging up
[23:40:39] <niedzielski>	 mdholloway|brb dbrant: hm, maybe it is an infinite loop
[23:40:57] <niedzielski>	 mdholloway|brb dbrant: if you scroll down a little, it stops
[23:41:31] <niedzielski>	 mdholloway|brb dbrant: looks like it repros on ics and marshmallow at least
[23:42:11] <dbrant>	 niedzielski: lol oh yeah! i get an infinite loop of additional search results...
[23:42:32] <niedzielski>	 dbrant mdholloway|brb: i'm checking the last release now to see if it's a regression or not
[23:46:37] <niedzielski>	 dbrant mdholloway|brb: shoot, i think it's a regression
[23:47:43] <niedzielski>	 dbrant mdholloway|brb: we shouldn't release with this bug. i'll make a card for it. try again tomorrow?
[23:48:16] <dbrant>	 niedzielski: agreed. we'll regroup tomorrow.
[23:48:36] <mdholloway>	 niedzielski: dbrant: yep, just got the same result.  sounds good.