[06:40:46] [android-commons] yuvipanda pushed 2 new commits to master: http://git.io/yw2E7A [06:40:46] android-commons/master 640a1da YuviPanda: Update to latest version of Support Library [06:40:46] android-commons/master 5396541 YuviPanda: Stop leaking Service Connections! [06:41:29] Project Android-Commons (mobile) - Nightly builds build #68: SUCCESS in 42 sec: https://integration.mediawiki.org/ci/job/Android-Commons%20(mobile)%20-%20Nightly%20builds/68/ [06:41:30] * yuvipanda: Update to latest version of Support Library [06:41:30] * yuvipanda: Stop leaking Service Connections! [07:06:14] [android-commons] yuvipanda pushed 4 new commits to master: http://git.io/bWmFkw [07:06:14] android-commons/master 1ec9be0 YuviPanda: Fix to make notifications not crash in 2.3... [07:06:14] android-commons/master 45f11aa YuviPanda: Update text for Notification to better fit available width [07:06:14] android-commons/master 604ba49 YuviPanda: Update IntelliJ file [07:06:30] Project Android-Commons (mobile) - Nightly builds build #69: SUCCESS in 28 sec: https://integration.mediawiki.org/ci/job/Android-Commons%20(mobile)%20-%20Nightly%20builds/69/ [07:06:30] * yuvipanda: Fix to make notifications not crash in 2.3 [07:06:31] * yuvipanda: Update text for Notification to better fit available width [07:06:31] * yuvipanda: Update IntelliJ file [07:06:32] * yuvipanda: Minor spacing fix [07:28:12] [android-commons] yuvipanda pushed 1 new commit to master: http://git.io/clSIbA [07:28:12] android-commons/master 8f75ed2 YuviPanda: Fix bug in releasing service connection [07:28:29] Project Android-Commons (mobile) - Nightly builds build #70: SUCCESS in 28 sec: https://integration.mediawiki.org/ci/job/Android-Commons%20(mobile)%20-%20Nightly%20builds/70/ [07:28:29] yuvipanda: Fix bug in releasing service connection [08:01:25] YuviPanda: ping [08:01:47] notnarayan: pong. [08:01:59] about to pack up and leave Pune. 'sup? [08:02:10] detail page has been updated. have a look at it when free. [08:02:34] YuviPanda: https://upload.wikimedia.org/wikipedia/commons/c/c6/Commons_media_discovery_app.png [08:03:21] will do [08:04:09] notnarayan: I just found out that there are stencils for various android design patterns on the android design site. [08:04:20] should be useful to avoid problems like non-standard action bar sizes, etc [08:04:21] brb [08:04:46] YuviPanda: i use them all the time. [08:05:43] notnarayan: oh? [08:05:45] interesting. [08:06:03] the non-standardish fonts and positioning on the action bar keeps throwing me off [08:06:15] YuviPanda: see some of the initial iterations. [08:07:00] notnarayan: are you going to update https://upload.wikimedia.org/wikipedia/commons/c/c6/Commons_media_discovery_app.png to go back to action bar at the bottom, instead of the floats? [08:07:46] plus lots of weirdness. The icon seems to be default commons icon rather than the one you made (with white background), for example [08:09:02] wooohooo 2.3 stuff done. yay. [08:09:09] YuviPanda: well while i was making this, i wasn't sure if using the white would be ok. Iv got a conformation on that :) will change that. again thats trivial, ill give you the icons when you need them no. [08:09:23] [android-commons] yuvipanda pushed 1 new commit to master: https://github.com/wikimedia/android-commons/commit/8b0d0b3a4eb43f07fad05d0cfa487cb05303fc6c [08:09:23] android-commons/master 8b0d0b3 YuviPanda: Fix missing Content Provider in Android 2.3... [08:09:35] YuviPanda: about the action bar on android, it would become a lil inconsistent with iOS app :( [08:09:39] Project Android-Commons (mobile) - Nightly builds build #71: SUCCESS in 28 sec: https://integration.mediawiki.org/ci/job/Android-Commons%20(mobile)%20-%20Nightly%20builds/71/ [08:09:39] yuvipanda: Fix missing Content Provider in Android 2.3 [08:11:03] notnarayan: that is expected. [08:11:08] this is an Android app, not an iOS app, no? [08:11:25] as a User, I'm going to be switching between apps on my phone, so switching between iOS or android apps [08:11:34] not iOS *and* android apps [08:11:51] YuviPanda: its not that major really. a lot of apps have non standard controls. [08:12:00] and people do not like those [08:12:52] do you remember the hate that Java Swing apps used to get? [08:12:56] that's almost decades back. [08:13:13] YuviPanda: if everyone used the android standard stuff, won't all apps look the same? anyway, ill update it with a split action bar at the bottom. [08:13:41] notnarayan: they'll look the same only if they are built for doing the same things the same way [08:13:45] which I guess they are not :) [08:13:52] notnarayan: we should not be different for the sake of being different. [08:14:27] YuviPanda: one sec, do you need a mockup of how the split action bar would look like, haven't you already done that in the app [08:14:41] i guess you need the icons [08:15:16] notnarayan: well, more because anyone looking at the mockups will be misled... [08:15:40] YuviPanda: i see. ill update it to a boring scheme :| [08:19:54] notnarayan: I'm flying to blr today :) [08:20:02] meeting Vijay [08:20:13] YuviPanda: how long will you be in blare? [08:20:29] I think till weekend. Are you working from bhutan? [08:20:45] YuviPanda: yea [08:21:02] notnarayan: okay. I'll come over tomorrow late-morningish [08:21:16] YuviPanda: nice! [12:01:36] New patchset: Zfilipin; "Updated multi_json Ruby gem" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/48840 [12:01:36] New patchset: Zfilipin; "Updated Ruby gems" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/49819 [16:05:15] New patchset: MaxSem; "Increase geosearch radius to 10km" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/49833 [17:21:07] MaxSem: hi! i saw your solr monitoring changes have all been merged [17:21:23] and reverted and then merged again [17:21:29] and still not live [17:21:36] o_O [17:21:49] ok - are they all merged, just needing to be pushed now? [17:22:06] i'll need to ask paravoid [17:25:31] * YuviPanda looks around [17:26:15] awjr, are we deploying today? [17:26:32] MaxSem: that is currently still the plan [17:26:43] though i havent checked with michelle or looked at the logs yet to see what is ready to go [17:27:07] can you merge https://gerrit.wikimedia.org/r/23108 ? [17:31:42] yeah MaxSem, i'll take a look shortly [17:32:02] also, https://gerrit.wikimedia.org/r/49833 [17:33:49] awjr, what's the use case for https://gerrit.wikimedia.org/r/#/c/49354 - "uploaded an image using MobileFrontend"? [17:34:52] one sec MaxSem [17:36:45] MaxSem: details here: https://mingle.corp.wikimedia.org/projects/mobile/cards/397 but the idea is to be able to stick in a template or whatever for identifying mobile uploads [17:37:08] aha [17:37:18] so the string shouldn't be long [17:39:40] YuviPanda: ping [17:42:05] YuviPanda: I have to postpone our Android training again [17:42:21] right now i'm holding on to the theory that the Android SDK broke my macbook :D [17:42:27] but it's not proven :D [17:43:00] when in doubt, blame the sdk :D [17:43:20] MaxSem: i think it can be arbitrary [17:43:55] brion: my new motto [17:43:56] :D [17:44:06] whatsup jcmish, survive the apple store [17:44:07] ? [17:44:18] nope awjr can't get in for an hour [17:44:20] yeah - but I wanted to know how long it can be in a typical use case (aka for us) so that I could decide if it's worth to load it on every page view [17:44:33] so sitting at home trying to see what I can do with my iMac :D [17:44:55] MaxSem: ah gotcha [17:44:59] heh [17:45:17] brion: pong [17:45:22] fixes the 2.3 issues - all of them :D [17:45:24] jcmish: ah [17:45:28] that's... difficult [17:45:34] (to break macbook by sdk) [17:45:35] YuviPanda: yay! just wanted to check in on the 2.3 stuff since i've got my emulator booted [17:45:42] brion: give it a shot. [17:45:48] brion: so no progress bars in notifications for 2.3 [17:45:54] but I think that's an acceptable compromise [17:45:55] sync provider is working \o/ [17:45:59] I've spent far too many hours on that. [17:46:02] brion: indeed. That too :) [17:46:20] brion: only problem is flickering images on progress, which I'm now looking into [17:46:29] brion: but majority of problems are fixed! :D [17:46:47] nice [17:46:58] hmm somehow taking a simulated picture i got stuck in landscape mode [17:47:01] apparently it is possible that I've the beginnings of a slipped disc in my back, so getting schooled in not killing myself [17:47:07] brion: pffft. emulators [17:47:16] wish the android emu had a damn menu to remind you of the hotkeys [17:47:24] YuviPanda: ooooooowwww [17:47:44] brion: owww indeed. I have had chronic pain there for a while, but when you get in the zone and write code it is sortof hard to notice [17:48:18] YuviPanda: oh no! [17:48:50] Being a 'travelling programmer' is apparently not good for your back [17:49:05] YuviPanda: i have some difficulty with the details screen where you input the title & description; it won't scroll and I can't easily get from the description field to the upload button [17:49:14] this is on simulated nexus one [17:49:25] YuviPanda: do some physical therapy if you can! a slipped disc is NOT fun at all :( [17:49:31] jcmish: our meeting clashed with Mobile App syncup, so wanted to push it anyway [17:49:39] awjr: indeed. I've to schedule an appointment. [17:49:49] problem is *where*. I'm not in one city for more than 3 weeks... [17:49:51] (or 2) [17:49:52] two years ago i had disc in my back slip the day before a 3-day trip to Austria... [17:49:55] YuviPanda: cool [17:49:56] ow [17:49:58] it was a really shitty trip [17:50:08] brion: with keyboard on or without? [17:50:15] YuviPanda: let's shoot for Thursday [17:50:21] brion: so the description field is multiline and I believe that is what is causing the problem. [17:50:26] YuviPanda: showing on-screen keyboard, but i was typing with the physical one [17:50:32] question is should it be or not. [17:50:36] yeah, hitting "enter" just does return in there. [17:50:50] brion: right. that's a general problem, I guess. our screens don't respond properly to having a keyboard present [17:50:53] YuviPanda: yeah, that's tough - if you can be in one spot for a few weeks to go through the PT, you can start doing all the exercised and stuff on your own once you've gone through things with a doctor [17:51:17] ok so that's one we can mark down to fix next iteration or two :) [17:51:36] New review: awjrichards; "Patch Set 1: Verified+2" [mediawiki/extensions/MobileFrontend] (master); V: 2 - https://gerrit.wikimedia.org/r/49833 [17:51:43] New review: awjrichards; "Patch Set 1: Code-Review+2" [mediawiki/extensions/MobileFrontend] (master) C: 2; - https://gerrit.wikimedia.org/r/49833 [17:51:45] Change merged: awjrichards; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/49833 [17:51:57] java.io.FileNotFoundException: https://upload.wikimedia.org/wikipedia/test/thumb/b/b4/Android_roxxors-.jpeg/320px-Android_roxxors-.jpeg [17:52:06] not falling back yet if the estimated thumbnail fails? [17:52:11] that's ok we'll get to it [17:52:18] jcmish, are we in a merge freeze? [17:52:39] MaxSem: I'm digging through what we hae [17:52:53] was gonna ask awjr are we still deploying today [17:52:54] or do we do it tomorrow instead? [17:52:56] we are [17:53:13] jcmish: yes, we have had no change in plans [17:53:27] awjr: the mingle boards are up to date yes? [17:53:40] jcmish: afaik, i havent looked at the logs yet so i dont know what current state of things is [17:53:49] YuviPanda: if you can't make the progress bar work on 2.3, we'll just live without the bar i think. we're being generous in working on 2.3 at all ;) [17:54:08] awjr: gotcha umm I can't get the logs going until I get my machine back online [17:54:15] brion: that's weird. why did it fail? [17:54:29] so yup MaxSem we're in freeze but I don't know where it starts :D I'm looking through gerrit now [17:54:32] YuviPanda: original file is 320x240, so it won't create a thumbnail at or larger than original :) [17:54:36] brion: indeed. The camera on the Galaxy Ace I have is pretty shitty. [17:54:41] brion: doh. No no fallback yet :P [17:55:01] i'm gonna keep after you on that one, don't forget it ;) [17:55:12] brion: on the plus side, our notifications on 4.x are now much nicer [17:55:16] since they're 'standard' ones [17:55:17] yay [17:55:20] awesome [17:55:31] and actually do indeterminate / determinate progressbars as appropriate [17:55:34] in proper Holo style [17:55:54] i'm seriously thinking of dropping iOS 5 support entirely, i've started depending on newer libraries and there's a jailbreak for iOS 6.x out now [17:56:15] awjr: yeah, a friend who went through a similar thing sat me down and gave me a stern lecture that has scared me sufficiently [17:56:20] at quick glance it looks like it'll be a pretty small deployment today - which will be nice after last week [17:56:39] it's TINY [17:56:43] I can't complain :D [17:57:13] good YuviPanda :) you definitely wanna get that taken care of and take steps to not let it happen again [17:57:24] tfinc is in a leadership thingy right? so I assume we're not doing our apps checkin with him today [17:58:23] brion: wasn't that last week? [17:58:23] or is that this week too? [17:58:29] was it? we'll find out soon enough :) [17:58:33] heh [17:58:48] it's hard to keep track of these things from afar [17:59:37] brion: we could just do it on IRC :P [17:59:40] * YuviPanda <3 IRC [17:59:52] true dat [18:00:54] brion: so on android I don't want to do the floating action buttons, but stick to the standard actionbar pattern [18:01:44] ok [18:01:59] going with the smaller grid? [18:02:10] brion: so that's another thing too. if we go with the smaller grid then no titles. [18:02:28] true, we lose room for that [18:02:49] what do you think about the idea of a zoomable grid? [18:03:19] brion: discovery would be a problem, I think. [18:03:27] plus it can't really 'zoom' smoothly, no? [18:03:33] especially if you want no empty spaces [18:03:52] you can go from 'enough for two columns' to 'enough for 1 column' but that's going to be not smooth [18:03:52] i'm happy to have some empty spaces between tiles [18:04:17] could have the zoom stick at appropriate-sized notches... [18:04:19] meh i dunno [18:04:56] brion: but how 'some'? If we have a 4dp padding for example, that still doesn't leave us much steps [18:05:31] yeah maybe not worth the effort. [18:05:41] could do a slider with fixed points but then it's not as pretty [18:06:13] MaxSem: merged https://gerrit.wikimedia.org/r/#/c/23108/ [18:06:21] thanks! [18:06:37] brion: indeed. And I dunno if not giving them a way at all to look at images + titles is a good ide [18:06:38] a [18:07:11] i think images are more important than titles, you can always get to the title on the detail view [18:09:48] brion: hmm, there's again the problem of images that look very similar [18:10:24] well what's the problem that needs solving? is there difficulty distinguishing between the images? [18:11:28] yes. [18:11:49] what is the user doing that they have to tell the pictures apart? [18:11:52] [android-commons] yuvipanda pushed 1 new commit to master: http://git.io/D4PfdA [18:11:52] android-commons/master 1a860c6 YuviPanda: Cleanup gridview code to use appropriate Java object [18:11:54] there's not even a detail view yet [18:12:18] Project Android-Commons (mobile) - Nightly builds build #72: SUCCESS in 32 sec: https://integration.mediawiki.org/ci/job/Android-Commons%20(mobile)%20-%20Nightly%20builds/72/ [18:12:19] yuvipanda: Cleanup gridview code to use appropriate Java object [18:12:24] and if there was, you'd see the titles in it :) [18:12:33] brion: that is true. I'll do detail view today. [18:12:42] spiff [18:12:51] brion: again, I'm not sure of thumbs only :P but simple enough to make 2 versions and test them around [18:13:02] \o/ [18:13:17] let's toss the issue at our designer friends [18:13:28] i just got a very ominous limechat alert. [18:13:35] hehe [18:13:37] hahaha :P [18:13:44] brion: should we toss it now? [18:13:51] sure [18:14:05] make sure we put it on the mailing list too so shankar and others can get in on it [18:14:50] munaf: 'displaying title + image on my contributions view vs just displaying images' [18:15:02] (user can tap on image to always view title + more info) [18:15:11] ooh updates to android sdk. this might fix my '4.2 emulator crashes' issue [18:15:25] brion: I'm happy to never have to use the emulator :D [18:15:32] * YuviPanda has a 4.2, 4.1, 2.3 device [18:15:55] i ordered a nexus 4 to run ubuntu phone on when the developer images come out :D [18:15:56] i'd definitely agree that we should display that info YuviPanda. will talk with shankar/vibha about whether or not tapping is the best affordance [18:15:58] too many devices... [18:16:04] er, not affordance, interaction [18:16:35] munaf: general problem is that we have to balance detail packing vs number of items [18:16:43] gotcha. [18:16:44] munaf: so that sortof blocks one other thing, that is if we display titles then we need to make thumbnails a little larger, and hence lesser number of items per screen [18:16:51] exactly. [18:17:06] big enough to show titles means we can only get 2-3 items on the screen at once [18:17:10] fair enough. we'll play with it :-) [18:17:36] indeed. The android code is flexible enough to make multiple variants of this particular issue in minutes, so... :) [18:17:39] greetings all [18:17:47] boooo, 4.2 emulator still crashes [18:17:51] howdy tfinc [18:17:55] good morning Lord Tomasz. [18:18:07] brion: MUNI wasn't too bad [18:18:10] tfinc: is your thingamajig all done and we're back on regular meeting schedule? [18:18:12] oh good [18:18:26] (me is in a different city now. yay) [18:18:28] i just have nightmares of flooded stations and stopped trains :P [18:18:37] YuviPanda: greetings Governor Panda. hows goes rule over the Android dominion ? are our battles successful ? [18:18:54] brion: you saw the video of van ness last year when that happened right ? [18:18:57] New review: MaxSem; "Patch Set 1: Code-Review+1" [mediawiki/extensions/MobileFrontend] (master) C: 1; - https://gerrit.wikimedia.org/r/49354 [18:19:06] tfinc: indeed. biggest demon from the lands of 2.3 compatibility issues has been slain! [18:19:10] whee [18:19:30] tfinc: and our EventLogging spies bring successful and accurate information from the enemy's every action. [18:19:37] (okay, user's) [18:19:46] :D [18:19:59] and I have stat1 access, and ori-l spent some time showing me the ropes, so all is well now :) [18:19:59] YuviPanda: then in the words of Worf. We shall destroy them. [18:20:01] YuviPanda: are we settled on the schemas? i've got preliminary support in iOS, just need to finalize and add to the login screen [18:20:22] YuviPanda: granted i'd like to think our users aren't our enemys but we are mere servants for them [18:21:02] omg the panda is planning an overthrow [18:21:05] tfinc: that works, but I think that wouldn't fit in with the 'battle' theme [18:21:08] android 2.3 users are slightly our enemy, but just because they're hard to support ;) [18:21:39] brion: android 2.3 is the enemy, not users :P [18:21:43] they need liberating, of course [18:21:50] users are occupied :D [18:21:59] indeed. [18:22:06] we should create an android 4 app for android 2.3 [18:22:23] yes, but set minimum requirement to 4.0 :D :D [18:22:28] cruelty! [18:22:39] 'Android 4 for Android 2.3' (Not compatible with your device) [18:22:51] YuviPanda: i got auto identify to work without any external tool for limechat [18:22:54] * tfinc is very happy [18:22:58] tfinc: :D [18:23:18] * YuviPanda still loves ZNC [18:23:26] especially now I have it automatically change my nick when I'm not there [18:23:37] i get stable logs and people can ping me anytime. [18:23:53] YuviPanda: i have been playing with tapchat, but it doesnt play very nice with znc [18:24:00] or at least, i haven't figured out how to get them to play nice [18:24:07] jcmish: do put our 'conquer android emulator' meeting in calendar [18:24:17] awjr: oh, as in, tapchat -> znc -> freenode? [18:24:21] yeah [18:24:23] YuviPanda: i really do love the bottom window of other channels now that i'm used to it [18:24:30] tfinc: YES! It is amazing [18:24:31] YuviPanda: yup one other question [18:24:39] all IRC clients should steal that feature [18:24:41] YuviPanda: are you on the design mailing list? [18:24:43] do you like earlier in the day? [18:24:49] brion: no. I shall be now. [18:24:58] jcmish: sure! [18:25:02] Not sure what time you work... [18:25:03] excellent. there's a thread on the commons app shankar started last week, we can add to it [18:25:05] cool [18:25:07] jcmish: me neither :P [18:25:10] hahaha [18:25:21] the problem is, the tapchat server is basically an always on client to ZNC - even when you're not connected to tapchat. this means you kinda lose out on some of the nice htings about znc (logged backscroll while you were disconnected, znc modules that do things when all clients disconnect [eg auto away]) [18:25:35] tfinc: https://commons.wikimedia.org/wiki/File:Yuvi_GNUnify_2013.jpg :P [18:26:39] awjr: quick get a mustache on https://commons.wikimedia.org/wiki/File:Yuvi_GNUnify_2013.jpg so that it scares me less [18:27:06] hahaha [18:27:20] tfinc: i already have more of a mustache than yuvi in that pic, it's on it's way back :) [18:27:25] :P [18:27:32] awjr: I now have a lazinessbeard/moustache [18:27:47] \o/ [18:27:54] YuviPanda: mine has now surpassed the lazybeard/stache and has entered the why-doesn't-he-groom-himself phase [18:28:02] :D [18:28:14] i think it will be stuck there for a while :p [18:29:07] brb [18:30:10] tfinc: are you in the office or do you have the leadership event still on? [18:30:16] YuviPanda: i am in the office [18:30:24] right. so meeting in 30 [18:30:25] and am super powered with leadership skills now [18:30:42] shall we all call you Lord Tomasz/ [18:30:43] ? [18:30:47] tfinc: uhoh we don't want you practicing on us [18:31:09] hmm, I don't find notnarayn online [18:31:18] geez this 'fix your posture' thing is hard. [18:34:44] back [18:34:55] awjr: MaxSem: is everything settled with open source days logistics ? [18:34:58] brion: can you respond on the design thread? I just subscribed would be hard to respond, I suppose [18:35:06] (that and I am lazy :P) [18:35:08] yep [18:35:12] heh [18:35:28] awjr: I just read Mark's response [18:35:40] so does this mean for squid configs [18:35:42] we are good to go? [18:35:47] brion: also Creation API? :P [18:36:05] ah i'll have to finish that up this week so we can use it next iter or so [18:36:07] tfinc, I'm waiting for visa and thus tickets are not purchased yet (the embassy recommends it this way) - other than that should be ready to go [18:36:36] brion: yup! [18:36:48] jcmish: possibly, it sounds like antoine has already taken initiative on it and is already close :) [18:37:06] MaxSem: k [18:37:17] awjr: good stuff [18:37:23] MaxSem: awjr: where are you with prep for the actual work @ open source days ? [18:38:52] tfinc: awaiting an agenda, and max and i still need to sync up about any other logistical stuff for on the ground in denmark that needs sorting [18:39:17] brion: ion has unsuccessfully tried to message you about tech screen. please respond to him as we want to move through the next round fast [18:39:40] tfinc: ok [18:40:05] YuviPanda: what have we learned from your access to stat1 ? [18:40:26] tfinc: that, perhaps, the current level of eventlogging might be a bit... too much? [18:40:30] especially recording Usernames [18:40:34] but other than that, nothing. [18:40:41] YuviPanda: we could care less about usernames at this point [18:40:42] because we dont' have people usint it yet [18:40:59] tfinc: unique identifiers. [18:41:27] so I can tell you exactly who tried to upload what file at what time, and if it suceeded or failed [18:41:29] same with login [18:41:43] and I can also tell if someone thought of uploading a file but cancelled [18:43:42] login successes, failures, and why they failed [18:43:46] i care if someone rant into that but at this point i dont need to know who that was [18:43:47] tfinc: I think that's pretty complete enough. [18:43:50] knowing what happens is enough [18:43:55] nice [18:44:21] we're recording usernames because that's the easiest way to track unique users (mobile web has easy access to tokens, we don't) [18:44:28] tfinc: oh, and I also know which method they used to upload [18:44:38] gallery, camera from inside app, or via 'share' from another app [18:45:25] YuviPanda: sent to design list [18:45:27] YuviPanda: setup a dashboard so that i can start seeing those [18:45:37] we want that before the apps go live in the store later this week [18:46:11] tfinc: I'll talk to Maryana and figure out what to do. Maybe there's one from analytics already that we can use (that would be nice). If not I can put up a simple one with key metrics. [18:46:31] YuviPanda: ask maryana and just plug into LIMN [18:46:40] tfinc: ok arranged tech screen call w/ ion [18:47:01] YuviPanda: something like this as the first pass is fine http://toolserver.org/~dartar/reg2/#mobile [18:47:06] I also need to submit the wikimania form that erik sent out [18:47:18] i dont need pretty. i just need update numbers that i don't have to ask you for [18:48:58] Maryana: how easy / hard do you think would be putting up something like that? [18:49:08] yuvipanda: a dashboard of what? [18:49:58] Maryana: Uploads. And logins. [18:50:08] tfinc: meeting in 10? [18:50:15] YuviPanda: yes. i cut it down to 30min [18:50:25] yeah saw that. good call, I think [18:50:29] YuviPanda: will shankar be there ? [18:50:45] tfinc: I just texted him. [18:51:53] yuvipanda: unfortunately, i'm no dashboards expert. uploads would be good to graph as a time series, but it doesn't seem like logins would be super helpful for an app - you'd get a spike of users logging in and then a drop, since they'd all stay logged in, right? [18:52:56] Maryana: right. [18:53:16] sounds reasonable. Is there someone at analytics I can poke? [18:53:16] Maryana: wont they have to fetch a new login token ? [18:53:16] err [18:53:17] YuviPanda: --^ [18:53:18] tfinc: nope. [18:53:23] nice [18:53:36] password saved. so only if they actually *change* their passwords do they have to do something [18:53:51] (password saved with Android's account manager stuff, so not going to be snooped by other apps, etc) [18:53:53] YuviPanda: so how could i see people who are launching the app but not uploading photos ? [18:55:11] yuvipanda: dan andreescu is the points person for limn [18:55:24] tfinc: 'set of people who have logged in' - 'set of people who have uploaded one picture' [18:55:39] Maryana: what is his nick? millimetric? [18:55:45] YuviPanda: thus i need the number of people have logged in as asked for [18:55:49] hmm, not sure.. [18:55:50] dont scratch that [18:56:44] Maryana: yeah, that's him [18:58:18] finally http://android-developers.blogspot.com/2013/02/security-enhancements-in-jelly-bean.html#secure-debugging [18:58:21] \o/ [18:59:30] * YuviPanda clicks [19:24:18] brion: I also see no email from you on the design list archives? [19:24:36] oh nevermind [19:24:42] ah good :D [19:33:38] brion: I'm going to add a field to both schemas identifying the device [19:33:53] brion: let's just make it 'DeviceName / OSVersion'? [19:33:57] device meaning OS, CPU info, or device model? [19:34:07] some identifier [19:34:14] 'DeviceModel / OS Version' [19:34:19] anything else you think we'll need? [19:34:26] (we don't need a full UA, since that is a lot of cruft) [19:34:39] so like 'iPod5,1 / iOS 6.1' ? [19:34:54] we should probably include application version too [19:35:02] in a separate field? [19:35:09] brion: yup. [19:35:24] brion: or actually no. Since app version is dependent on OS [19:35:36] well [19:35:54] "Commons-iOS/0.1" "Commons/Android/1234.awesome" [19:35:59] or some such :D [19:37:11] brion: Commons 0.1 / iOS 6.1 / iPod 5.1 [19:37:11] ? [19:37:11] or something like that [19:37:34] hmm i wonder if it should just be three fields [19:37:43] what kind of device/model info can you get on Android? [19:37:50] anything you want :P [19:37:55] but I don't want to do more than Device Name [19:37:58] heh [19:37:58] should be good enough for us [19:38:18] should we be recording language usage or anythign? [19:38:57] brion: good question. Not right now I'd say. [19:39:05] because we can't really do much with it [19:39:11] yeah [19:39:22] might make the translatewiki people happy to see their translations being used though :D [19:39:25] but no rush [19:42:42] let me confirm i can get hardware model on iOS... [19:43:37] hmmm it tells me 'iPad' but not the model number [19:44:48] ah i can get it though [19:45:46] brion: sweet. I'm adding it now [19:46:00] all right, unix wins again :D [19:46:09] 'uname' returns the model, like 'iPad2,5' [19:46:18] it's not pretty format, but it'll distinguish models [19:46:21] brion: so, 'Commons/ OS/ Model [19:46:22] ' [19:46:23] works/ [19:46:57] so on the iPad mini i'd return like "Commons/0.1 iOS/6.1 iPad2,5" [19:46:58] ? [19:47:03] brion: i should actually check with analytics to see which is easier, one or 3 [19:47:08] yeah :D [19:47:19] i've a suspicion it'll be 3 :P [19:47:24] :) [19:47:33] it's big data, go crazy ;) [19:48:01] true [19:48:10] tfinc: can you confirm https://www.mediawiki.org/wiki/Apps/Commons#Reports is all the reports you'll want now? [19:48:27] and that nothing obvious is missing? [19:48:36] brion: ^ [19:49:00] looking [19:49:22] how are we determining unique users? [19:49:36] brion: you might want to sit down for this [19:49:42] currently, we're tracking Usernames [19:50:17] yeah… we're gonna need some new covers on those TPS reports [19:50:26] :P [19:50:38] so I'm unsure if we should salt and hash those or not. [19:50:45] we… probably should [19:50:45] (currently we are not) [19:51:05] but I'm unsure, since *most* of it is associated with their name anyway (if they upload it is in revision history, etc) [19:51:12] however if you can attach an upload event's time to a completed upload, you can obtain the username [19:51:18] yeah :P [19:51:22] so, we're tracking filenames too [19:51:32] (since a lot of errors hit abusefilter / titleblacklist) [19:51:39] so you don't even need upload event :P [19:53:40] brion: from talking to Maryana I gathered that this is OK, since we're not tracking anons, but people who have logged in [19:53:40] I might have misunderstood [19:53:59] whee [19:54:34] this scrolling feed of conversation from all channels in LimeChat is wonderful for serendipitously trolling unsuspecting people on channels i'm not participating in [19:54:59] brion: those reports look okay? [19:55:11] hehe [19:55:38] how do we report inactive logins, exactly? or is that a report made from the data [19:55:40] yuvipanda: yes, logged in user actions are fine to track, as long as they're not associated w/private data like IP, etc. [19:56:09] Maryana: GPS position, secret camera photos of the users as they upload…. anything else we can squeeze in? ;)) [19:56:21] Maryana: right. and even 'cancelled' or 'failed' actions are fine (login failed, upload failed, etc) [19:56:53] brion: Batman style surveillance via Audio Capture. [19:57:33] :) [19:57:57] event_social_security_number [19:58:12] @_@ [19:58:43] hey, nobody has explicitly forbidden it! [19:58:45] :D [19:58:49] juuuuust kidding [19:58:57] hahaha [19:59:14] * awjr makes mental note to be extra vigilant during coder eview [19:59:29] social security number is US-centric. use a DNA profile instead [20:00:05] ugh i used up all the space on my retina iPad. time to delete some unneeded games [20:00:35] i wonder how long it would take for a mobile device to be able to decode dna [20:00:35] man these games gotta start using the "internet" to stream "data" without storing it on my device [20:00:41] cut the rope is 400 freaking megs [20:02:12] do we need to update those schemas? [20:02:20] brion: currently updating as we speak [20:02:28] excellent [20:04:02] brion: updated [20:04:31] tfinc: seen https://www.mediawiki.org/wiki/Apps/Commons#Reports? I'm talking to analytics about dashboards, so finalizing what we'll need for first cut [20:04:39] might want to say 'device model' rather than 'device name' [20:04:47] ios's concept of device name is like 'Brion's iPad' [20:04:48] :P [20:04:54] oh dear [20:05:23] brion: done. [20:05:40] +1 [20:05:59] brion: I guess I'm sleepy. The prose for those descriptions suck [20:06:04] :D [20:06:08] i'll add some examples and stuff [20:06:24] YuviPanda: so for model do you get a user-legible string like 'Galaxy Nexus' or what? [20:06:32] yes [20:06:37] nice [20:07:12] YuviPanda: i was also thinking we could add a separate error detail field in addition to 'result' [20:07:23] brion: https://developer.android.com/reference/android/os/Build.html [20:07:25] lottainfo [20:07:27] so e.g. if there's a generic network error, but we get something specific reported to us internally, we can use that [20:08:28] brion: like what? [20:08:42] I was trying to think of network errors that aren't a timeout or unreachable or DNS or whatever. [20:08:50] would differentiating it actually help us? [20:08:54] well, maybe not [20:09:01] We know two well-known values [20:09:06] 'succes', 'cancelled', 'network' [20:09:11] everything else is an API error [20:09:16] ok [20:09:24] that should work well enough then [20:09:27] yup [20:09:33] API error should never be "success" or "network" or whatnot :) [20:09:44] exactly :P [20:10:56] ok i'm happy enough with those schemas for now [20:11:57] sweet [20:15:18] brion: gaah. I spend 3 days trying to fix the notifications bug, and today I see https://code.google.com/p/android/issues/detail?id=30495 [20:15:19] grrr [20:15:35] but I think I'm going to leave it as is. I quite like the default notification layout on 3.x+ [20:15:35] heh [20:16:14] ok i'm gonna eat some lunch and then update the event logging [20:20:43] New review: JGonera; "Patch Set 1: Code-Review-1" [mediawiki/extensions/MobileFrontend] (master) C: -1; - https://gerrit.wikimedia.org/r/49354 [20:38:56] New review: awjrichards; "Patch Set 1: Code-Review+1" [mediawiki/extensions/MobileFrontend] (master) C: 1; - https://gerrit.wikimedia.org/r/49195 [20:43:08] we've got deployment soon, but I'd be glad if someone could review some of my commits after it. I was hoping some of them would get merged before the deployment [20:43:23] if anyone wants me to review something, add me as a reviewer in gerrit [20:50:55] New review: awjrichards; "Patch Set 2:" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/49184 [20:51:31] New review: awjrichards; "Patch Set 1: Code-Review+1" [mediawiki/extensions/MobileFrontend] (master) C: 1; - https://gerrit.wikimedia.org/r/49271 [20:51:40] brion: http://etherpad.wikimedia.org/mobile-app-dashboard has graphs! [20:51:44] well, things we want in graphs at least [20:51:57] :) [20:52:03] note to myself: old production was 65fee307fb9dde7b663870ad780ff57df71e9462 [20:53:31] awjr, jgonera, I'm preparing to deploy [20:53:40] sadly, no jcmish around [20:53:43] ok [20:53:44] awesome MaxSem, im standing by [20:53:49] hmm [20:54:02] her laptop is probably dead [20:54:10] hopefully she's back soon [20:54:30] i'll see if i can get in touch with her [20:55:06] YuviPanda: are we handling the case where we get a generic API error result instead of the upload or login result? might get that for things like DB failures [20:55:32] brion: in the app or in logging? [20:55:40] either [20:55:41] in logging whatever error the API returns will be logged [20:55:50] in the app we just will say 'failed' and let them try agian [20:56:13] i suspect i'll crash due to looking for things that don't exist in the json dictionary [20:56:29] without doing sufficient error checking for whether i got upload/login or error back [20:56:37] I've a guard in the code looking for result success in my code [20:57:02] i could turn an error result from the api into a failure case [20:57:14] but then we're dropping the error code given, if any [20:57:20] it'd just show up as "network" [20:57:40] ? [20:57:50] i'm just sending (into eventlogging) whatever I get back from [20:58:49] hmm [20:58:59] {"servedby":"mw1195","error":{"code":"unknown_action","info":"Unrecognized value for parameter 'action': asdfklj"}} [20:59:07] so taking the 'code' or the 'info'? [20:59:16] ori-l, Maryana_lunch told me that she'd like to have isEditable field in https://meta.wikimedia.org/wiki/Schema:MobileWebUploads. do you have any idea how I can get this information about a page? she told me E3 was doing something similar in Getting Started [20:59:20] brion: code [20:59:33] not logging 'info' [20:59:39] * brion checks more documentation to see what actually happens on various errors [21:00:22] ugh why are the responses pre-collapsed on https://www.mediawiki.org/wiki/API:Login ? [21:00:27] that's like the only part i want of the page :) [21:00:47] :D [21:00:58] "Errors are returned in the result field. Possible values are:" [21:01:01] hmm [21:01:17] so i might have data[@"login"]["@result"] or I might have data[@"error"][@"code"] [21:01:52] or I might have a network error [21:02:22] brion: :D [21:03:20] this is where I'd like to return "error" results as failures so I can at least consolidate two of those cases… I can probably subclass NSError or something [21:03:30] * brion goes to read more background on obj-c errors [21:03:37] :D [21:03:46] brion: I'm heading to sleep [21:03:48] good night :) [21:03:52] nighty night [21:03:54] dream of java code :) [21:04:11] brion: might possibly. :) [21:04:16] hehe [21:04:17] good night [21:05:00] MaxSem: just heard from michelle and she is around to test although i think currently reachable only asynchronously. [21:05:28] sehr gut [21:06:46] ahahaha [21:06:47] http://test.m.wikipedia.org/ [21:06:53] Error 503 Service Unavailable [21:07:07] damn it [21:10:16] shouldn't we use beta instead of test? [21:11:40] beta's not quite ready for staging jgonera [21:12:10] I see [21:12:11] jgonera: are there any ops around in the office? [21:12:39] I can only see CT [21:12:47] yeah, ct just told me they all left for lunch [21:12:50] >_< [21:13:04] yeah, i saw them all walk out as i was coming in a few min ago [21:13:52] brion: i'm failing to find a new windows 8 test image. can you help me out? [21:13:59] jgonera: I'll have to look to make sure, but I think after first rejecting the idea is being ugly and implementation-specific, we eventually realized checking for the presence of an 'edit' tab was the most reliable method. [21:14:14] * as being. [21:14:32] hm [21:15:00] I think S Page (irc nick: spagewmf) tried various 'nicer' (read: more abstract) approaches that all ended up not covering some particular set of cases. You might want to poke him for details. [21:15:02] i asked ct directly if there's anyone else who can look into it but still waiting on response [21:15:31] I'm also not sure about the field token, Jon used the token generated for edit action when logging watchlist events, but this does not identify unique users [21:16:01] I mean, for example in photo uploads we have a different token for the upload itself and for updating the wiki text of a page [21:16:15] so... it will look like two different users if I use that, right? [21:16:57] jgonera: I think how I'd approach it, though, is grep through core for the bit of code that adds the edit tab (rather than, say, 'view source') and see what values it is inspecting, and then add a MakeGlobalVariablesScript hook that checks the sample values and sets a javascript config var indicating the editability of the page that is being rendered. [21:17:32] oh, you want a unique token to identify users, that's something else [21:17:47] yes, sorry, that's a different question that I just came up with [21:17:57] the way I'd do _that_ is as follows: [21:18:00] but thanks for the hint on the previous one ;) [21:19:00] on _any_ attempt to log an event, use check localStorage for the existence of some predfined key ("uniqueToken" or whatever). if it's there, add it to the event object; if it's not there, generate it and add it [21:19:36] if you want to know how many unique visitors you have, you can implement code that runs on page load and does that, with the caveat that if the key already exists no event is logged [21:19:42] hm, why not simply use PHP's sessions (are we using them)? [21:20:11] so: localStorage['uniqueToken'] exists ? if yes -> continue, if no -> generate one and log it. [21:20:16] I'm just trying to generate appropriate data for https://meta.wikimedia.org/wiki/Schema:MobileBetaWatchlist now [21:20:22] they're scoped to sessions [21:20:30] ok, let me take a look at the schema [21:20:32] yeah, I understand the approach [21:21:01] just wondering if PHP session id wouldn't be easier, since it's already generated [21:21:20] is it always generated? [21:21:31] including for anons? [21:21:31] using php sessions for anon users would totally break caching for mobile [21:21:34] hm, let me check [21:21:35] right [21:21:50] because if you're relying on php to generate the value for each anon user, you're bypassing the cache. [21:21:55] exactly [21:22:12] you're right, they're not [21:22:28] what about browsers that don't support local storage? [21:22:29] as soon as a user gets a session cookie set, no more caching for them [21:22:33] by a function for generating an arbitrary string token is in core; it was not exported out of private scope but if krinkle merged my change it is now [21:22:34] let me check [21:23:04] well, forget it, we're not allowing anonymous users to uplaod anything ;) [21:23:23] so I actually can just use the PHP session ID, because it will be present for sure [21:23:59] I really don't think you should. The need to annotate events with tokens is not specific to uploads, so you may as well have an implementation that could be stretched for additional analytic needs [21:24:09] it's easy -- the functionality is in mediawiki.user.js [21:24:22] heh https://twitter.com/DEVOPS_BORAT/status/289782091250532352 [21:24:24] user.generateRandomSessionId() and user.sessionId() [21:25:20] where can I find docs about mediawiki.user.js ? [21:25:23] this is (relative to repo root) at resources/mediawiki/mediawiki.user.js [21:25:28] ok [21:25:45] I think the documentation is a bit sparse, but the doc strings are informative and the functions themselves are quite simple. [21:26:30] this uses a cookie to store the session id, namely mediaWiki.user.sessionId [21:26:37] right: I would avoid user.sessionId() [21:26:46] use user.generateRandomSessionId() and localStorage [21:27:01] cookies affect caching behavior, which you don't want [21:27:01] ok, so back to my question: what about browsers without local storage? [21:27:16] hrm. [21:27:31] So, I would probably use localStorage with a fallback to cookies [21:27:37] I think there may even be a JS module in core that implements that [21:28:20] that way, if you are using cookies, it's for a small subset of users, so if you end up bypassing the cache by accident it's not a disaster [21:28:21] hm, I'm checking caniuse.com, maybe I shouldn't even bother [21:28:32] yeah, localStorage is pretty widely supported. [21:28:35] ori-l: https://gerrit.wikimedia.org/r/#/c/42329/ [21:28:55] Krinkle: ah, there it is! thank you. [21:29:18] if Krinkle is here he knows about x100 more about this than I do :) [21:29:41] * Krinkle only read the stalkword line [21:29:49] What's up? [21:29:49] ok, I guess I'll settle for localStorage then [21:30:12] so, basically I need a unique id for users, for the purpose of logging what they're doing [21:30:26] ah, I found the other thing too: resources/jquery/jquery.jStorage.js [21:30:38] " just wondering if PHP session id wouldn't be easier, since it's already generated" [21:31:01] user.sessionId() is basically that, except that it doesn't isn't tied directly to php but more independant [21:31:08] cookieTracking used to use it [21:31:13] ext.ClickTracking * [21:31:13] yeah, I was just told not to use cookies ;) [21:32:05] as I was told, using cookies makes us bypass cache [21:32:34] although I'm still puzzled why we don't allow a unique session cookie which would be ignored by Varnish [21:32:41] MaxSem: let's give ops another 10 minutes; if they don't get it fixed by then let's just reschedule [21:33:05] Krinkle, ^ [21:33:29] jgonera: " as I was told, using cookies makes us bypass cache" [21:33:33] I'm not sure what you mean there [21:33:44] I know cookies makes the user bypass squid (not varnish) cache [21:33:54] but ui cookies afaik are not affected by that [21:33:58] " as soon as a user gets a session cookie set, no more caching for them" [21:34:06] jgonera: http://caniuse.com/#feat=namevalue-storage [21:34:13] if you want to know the relationship between cookies and squid and varnish, [21:34:14] Krinkle: certain cookies will cause a user to bypass caching of mobile varnish caches [21:34:17] gadgets and scripts set cookies all the time (doesn't make it right, but just saying, shouldn't affect caching in general) [21:34:19] you need to start reading up on X-Vary-On [21:34:23] mobile.. [21:34:24] right [21:34:26] and you don't want to start reading up on X-Vary-On [21:34:31] Krinkle: amongst them are regular session cookies [21:34:33] so just use localStorage if you can afford it, which I think on mobile you can. [21:34:51] ori-l, I know, I found it [21:34:56] I know enough about X-Vary-On to understand the problem with it. [21:35:29] But how/why does mobile do this different then regular production? [21:35:35] Krinkle: we actually unset all cookies except for a few at the varnish layer to avoid this problem. so you could theoretically set a certain cookie and not have any impact on caching if you only care about the cookie contents on the front end [21:35:37] yes, I'll just use localStorage I guess because I don't want to turn adding logging to photo uploads into a day long (or longer) investigation [21:35:57] jgonera: to store what? [21:36:14] use mw.user.sessionId() if you need a simple identifier for one user [21:36:15] the session id, generated by mw.user.generateRandomSessionId [21:36:26] Why do you need to generate a separate one? [21:36:33] but it uses cookies! [21:36:57] and this cookie makes it to mobile backend / is it a problem? [21:37:07] I don't know, I guess that's what awjr and ori-l are suggesting, and I don't want to learn all our caching details right now [21:37:13] it seems so [21:37:19] jgonera: what are you trying to achieve? [21:37:34] unique session id for logged in and anonymous users [21:37:44] jgonera: user.generateRandomSessionId() is just producing a value; it is not attempting to store it in any shape or form. use it and use localStorage as the storage medium. [21:38:03] this has the advantage of 1) not breaking the cache 2) re-using existing implementations [21:38:06] ori-l, yes, that's what I've just written [21:38:10] that should be fine [21:39:43] MaxSem: i just saw faidon merge a fix for test [21:39:47] https://gerrit.wikimedia.org/r/#/c/49925/ [21:39:50] me too [21:40:04] let's see when it gets pushed [21:44:06] ok MaxSem are you comfortable to keep going? [21:44:12] yes [21:44:27] if testing takes too long I might abort though [21:44:28] sweet let's do it [21:44:29] k [21:44:42] the code's already live, let's test it [21:44:50] jcmish, Maryana, jgonera ^ [21:45:05] on testwiki? [21:45:07] Cool [21:45:08] yep [21:45:08] awjr, jcmish, jgonera, Maryana ^^^ [21:45:15] great, I love the targets in ResourceLoader... of course mediawiki.user does not have mobile target so I can't use it unless I write a patch for core and that patch gets merged [21:46:03] maxsem ^ [21:46:04] :) [21:46:35] grmbl, that's why I proposed a different model for targets [21:46:54] jgonera, is it a live breakage? [21:47:13] MaxSem, no, that's unrelated, I just wrote that before I read about testwiki going live [21:47:41] but anyway, is your proposal published somewhere on the wiki, or in some changeset? [21:48:42] no, we discussed different approaches when we prepared the RL switchover [21:48:46] JS doesn't seem to work on my phone for some reason (menu loads as a separate page), anyone getting that too? [21:50:31] are upload errors expected on testwiki? [21:50:47] false alarm on my side [21:50:51] jgonera: im checking now - in stable? [21:50:51] what kind of errors? [21:50:55] k [21:51:06] if you're not an admin, then yes [21:51:14] (that's what I heard) [21:51:21] oh [21:51:25] i just get 'error try again' [21:53:48] that's unfortunately expected behavior on testwiki as far as I know due to permissions. I'd really like the testwiki to be a closer copy of real WIkipedia [21:54:05] I just got an error [21:54:15] huh i thought we were able to upload to testwiki [21:54:23] Trying to search [21:54:43] Is it just slow and I should try again? [21:54:53] for some reason that Jon knows the details of, only people with admin accounts on testwiki can upload there [21:55:28] jcmish: do you mean the autocomplete is slow? [21:56:04] search is working for me ok in ios simulator and desktop chrome (in stable) [21:56:13] Bringing up the article but I'm at Starbucks [21:56:33] So it could be their network.. Switching to LTE [21:58:33] K that works better but I can't upload an image either did we lose admin rights on test? [22:00:35] are you guys talking about the lead image upload or donate image? [22:00:49] i dunno why our permissions would have changed unless someone changed configs for test around upload permissions [22:00:50] Donate for me [22:00:51] testwiki user rights shouldn't affect the latter [22:00:59] both for me [22:01:00] since you're just donating to commons [22:01:14] Weird [22:01:59] lemme try uploading to commons on desktop [22:02:06] JIC it's a commons issue [22:02:24] Cool Maryana [22:03:00] it appears to be login related issue [22:04:19] im getting the 'mustbeloggedin' error from the api when trying to upload [22:04:33] does testwiki not log you in to commons as part of CentralAuth? [22:05:01] wtf it looks like i'm getting "filename-tooshort" errors on upload, but the uploads are going through [22:05:04] this is very confusing to me [22:05:05] uh o [22:05:13] is this related to jon's centralauth hack? [22:05:24] yeah, upload works fine on desktop commons [22:07:27] Other than uploads, everything else looks good on non beta and beta [22:07:34] Moving on to alpha [22:10:29] so, currently the upload endpoint for testwiki is commons - isnt it supposed to be local (eg if you upload from testwiki, you upoad TO testwiki not commons)? [22:10:36] MaxSem: ^ [22:10:43] it's been commons for as long as i can remember [22:10:49] huh [22:11:06] awjr, uploading to commons is the point of this [22:11:32] SUL doesn't appear to be working right from testwiki and im not sure why [22:11:33] we should be able to test the real workflow [22:11:38] I thought last time it was local... [22:11:46] i agree MaxSem but i thought our uploads for test had been local in the past [22:12:06] nope. i can see the test images i took from last deployment [22:12:21] they went to commons [22:12:31] * Maryana tries to upload on her phone [22:12:44] Same as Maryana I see mine [22:12:50] From last time [22:13:07] so when i log in to test and centralauth does its thing, i don't get the login images back from any of the other projects - i get http status 200's, but no images, so i dont appear toa ctually get logged in anywhere else [22:13:26] so, revert thaty change? [22:13:30] which would explain why im getting the not logged in error when trying to upload [22:13:46] but wasn't this change only a JS/CSS change? [22:14:00] error, try again [22:14:01] :( [22:14:13] awjr: that's jon's centralauth hack [22:14:17] that must be the issue [22:14:26] Maryana: wasn't that deployed last week? [22:14:40] it works in production [22:14:56] our devices might have been cached [22:14:57] I logged in to commons manually and it worked [22:15:02] login on our devices, i mean [22:15:03] (I mean the photo upload) [22:19:18] https://gerrit.wikimedia.org/r/#/c/48158/ this is the cantralauth hack [22:19:21] i see what happened… i had one image with a blank title that was in my queued uploads [22:19:25] ok api mystery solved \o/ [22:19:51] I don't think it broke commons login [22:20:17] and yes, it was already in production for the past week, so... [22:21:01] my image is infinitely uploading [22:21:32] i can check to see if there were any mobile uploads since our last deployment [22:21:33] ugh, that's why I want error logging before we move that to stable... [22:21:40] Maryana, ok [22:21:41] ^ +1 [22:22:10] [Commons-iOS] brion pushed 1 new commit to master: http://git.io/ofC2ew [22:22:10] Commons-iOS/master 184b2a4 Brion Vibber: start cleaning up error handling in the api module... [22:22:21] jgonera: aside from jon referring to 'centralnotice' rather than 'centralauth' in the comments in that commit, it should be fine (and appears to work fine in prod) so there might be something wonky about test (surprise!) i am inclined to deploy as-is and dbl check in production afterwards. esp since it's beta, im not super concerned. [22:23:12] yes, we can probably do that, photo uploads were broken for, probably 95% of users for the last week anyway [22:23:27] heh [22:23:33] MaxSem, Maryana, jcmish ^ [22:23:47] + 1 awjr [22:23:49] (because of the weird progress bar issue) [22:24:03] yeah, def let's roll out to production [22:27:41] ok then Maryana, jcmish - ready to go? [22:27:49] Yup [22:29:20] yep! [22:29:43] MaxSem: ^^ engage! [22:29:47] all right, scapping [22:30:20] and, um, it looks like there were no images successfully uploaded via the donate image link at all since last deployment [22:30:37] None? [22:30:42] New review: Cmcmahon; "Patch Set 1: Verified+2 Code-Review+2" [mediawiki/extensions/MobileFrontend] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/49819 [22:31:04] New review: Cmcmahon; "Patch Set 2: Verified+2 Code-Review+2" [mediawiki/extensions/MobileFrontend] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/48840 [22:31:06] Change merged: Cmcmahon; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/48840 [22:31:29] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/49819 [22:31:30] checking again just to make sure [22:31:32] New review: Cmcmahon; "Patch Set 1: Verified+2 Code-Review+2" [mediawiki/extensions/MobileFrontend] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/48261 [22:31:34] Change merged: Cmcmahon; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/48261 [22:41:10] Maryana, jcmish, that's not surprising, I guess that due to the upload progress bar only some very small percentage of browsers was able to upload something [22:41:29] (due to the problem with upload progress bar) [22:41:41] Ahh I missed that jgonera [22:41:56] Is it fixed now ? [22:42:28] zz_YuviPanda: i'll respond to diederik [22:46:00] jcmish, yes, should be [22:46:37] K cool [22:47:58] MaxSem: how long does scrapping take nowadays? [22:49:38] ~40 mins [22:50:09] K running home [22:54:45] * tfinc tries to not let the puppy in the office distract him .... fails  [22:55:17] hehehe tfinc who's puppy? [22:58:05] preilly: is fostering a puppy for the week and brought it into the office [22:59:06] the beast is too dangerous to keep it at home? [23:03:24] MaxSem: she is ferocious. what's out for your shoe laces [23:05:38] awjr, jcmish, jgonera, Maryana - scap complete [23:05:43] w00t! [23:06:42] Sweet [23:07:10] so uploading appears to work, however the upload counter appears broken [23:07:32] ori-l, just one last thing, can you point me to some real life usage examples of event logging, other than mobile? any extension or the core itself? [23:07:55] awjr, the upload counter wfm [23:07:59] orly? [23:08:18] it is saying 0 uplods for me :-/ [23:08:22] it's saying i have 4 uploads… which is not true! [23:08:24] and displaying some lovely photos i've taken :) [23:08:36] 0 for me [23:08:40] i wonder if it is reading from enwiki rather than commons [23:08:53] that might be the case [23:08:56] hmm [23:09:07] doh needs a conf change [23:09:13] wgMFPhotoUploadWiki [23:09:23] forgot about that, sorry MaxSem [23:09:54] but i have 5 enwiki uploads. [23:10:06] oh :( [23:10:07] and it says i have 4 uploads [23:10:40] hmm [23:11:44] mysterious mysteries [23:12:13] i have 4 if you don't count ones coming from the enwiki file upload wizard... [23:17:47] MaxSem: https://gerrit.wikimedia.org/r/#/c/49946/ [23:17:53] oh you already reviewed [23:18:14] ;) [23:21:02] non beta looks good [23:21:11] moving on to beta and then alpha :D [23:23:13] just tested donate image in beta - worked fine :) [23:23:24] and it actually went to the top of my uploads this time! [23:24:39] ok the donate upload page now shows upload stats from commons [23:25:31] does that mean https://bugzilla.wikimedia.org/show_bug.cgi?id=44693 is fixed? (the fact that new uploads are showing up at the top of my uploads now, instead of in random places) [23:26:29] awjr: success! [23:26:35] it's right now :) [23:28:24] yay! Maryana does the count look right for you :) [23:28:34] yep, just checked. it's right, including the image i just uploaded [23:28:40] Maryana, I don't think anyone tried to fix that bug [23:28:49] it may have fixed itself.. [23:28:53] maybe ;) [23:29:04] the best kind of bug fix! [23:29:13] alrighty things are looking good for beta and I'm finishing up alpha [23:29:26] * tfinc wants to smash window7 with a hammer [23:29:48] [Commons-iOS] brion pushed 3 new commits to master: http://git.io/jHuvfA [23:29:48] Commons-iOS/master b90be7f Brion Vibber: Clean up in MWApi... [23:29:48] Commons-iOS/master 543bf18 Brion Vibber: switch MWApiResult to NSDictionary with just the return data [23:29:48] Commons-iOS/master f66be80 Brion Vibber: drop some of the cookie bits from MWApi... [23:30:34] tfinc, MacOS homesickness?:) [23:31:26] * awjr hands tfinc a hammer [23:31:47] how are we looking? [23:32:46] could be worst tfinc you could be using the latest windows :D [23:32:55] I've been watching the blogs people are not kind [23:34:12] MaxSem: i think we're looking good - jcmish_, Maryana - prod look good to you? [23:34:33] yep, lookin' good [23:35:55] i hate it i hate it i hate it [23:35:56] yup [23:37:48] tfinc goes to play with the puppy instead :) [23:50:23] [Commons-iOS] brion pushed 1 new commit to master: http://git.io/QxGUeA [23:50:23] Commons-iOS/master 0dc60a3 Brion Vibber: Fix that memory leak in percent encoding [23:51:58] [Commons-iOS] brion pushed 1 new commit to master: http://git.io/2fMGUg [23:51:58] Commons-iOS/master 9835e06 Brion Vibber: another memory issue [23:55:17] brion, could you review https://gerrit.wikimedia.org/r/#/c/49195/ ? merging this would probably save me some rebasing in upload error logging later on [23:56:00] moment [23:56:07] looking [23:58:03] looks good [23:58:08] lemme do a quick local test [23:59:48] hmm still no upload in firefox? :(