[00:04:58] nzr: since the task got impossible to follow, i'll stop commenting on it [00:06:34] dr0ptp4kt: reset worked :) [14:45:01] cycling home [15:33:18] home -- near hit on the way back as a car pulled out in front of me :/ [15:40:01] phuedx: :( [15:40:35] mdholloway: i've been incredibly fortunate for most of my cycling career in that i haven't had to deal with aggressive drivers [15:40:43] *many aggressive drivers [15:40:56] but there's no avoiding people who look but don't see [15:41:45] yikes [15:44:00] ohh, i'm liking the improved API sandbox [15:45:24] ooh! [15:58:34] niedzielski: are you OK repping apps in the TWN workflow meeting? [15:58:47] i think only one of us needs to attend, and you're clearly more familiar w/ it [15:58:55] i can hop in if there are any specific questions you think i should answer [15:59:16] bgerstle: i can do that but i'm sure you're perspective would be valued as having newly switched [15:59:30] ok, i'll sit in [16:33:06] Jenkins jobs reports are delayed. Labs is under maintenance. [16:51:15] hashar: thanks for the heads up [17:16:08] niedzielski: anybody noticed some sort of excessive blinking when you tap on an image? Try 'sea' for example. [17:16:46] etonkovidova: i haven't but am checking now [17:19:30] etonkovidova: hm, i do see maybe one flicker when opening the image gallery but couldn't say offhandedly if it was a regression. [17:20:46] niedzielski: hmm... yes, it's in alpha too. It does not look like a bug - iOS present pics so smoothly [17:20:49] dbrant: will the next prod release include a cherry pick of https://phabricator.wikimedia.org/T126164 ? :) [17:20:55] niedzielski, bearND|afk ^ [17:22:28] FlorianSW: no, that merge happened after we cut the release (https://gerrit.wikimedia.org/r/#/q/status:merged+project:apps/android/wikipedia,n,z) [17:22:45] look for the bump version commit [17:22:47] FlorianSW: it barely missed the beta train. next release. [17:22:59] bearND: I know that, but in other projects it's possible to cherry pick important changes (and I would call this important) [17:23:19] and I'm not sure, if this is possible for mobile apps, too : [17:23:20] :) [17:23:42] etonkovidova: i think it would be fair to mark it as a bug or request for improvement. there are better transitions possible and that gallery screen could use some love [17:23:54] FlorianSW: then you'd need to introduce release branches, which we don't usually do [17:24:23] niedzielski: yes, you're right :) I'll file it as a bug. Thx! [17:24:42] bearND: you could checkout the release commit locally, cherry pick the change (locally) and generate a new build? :D [17:24:53] etonkovidova: niedzielski: no need -- https://phabricator.wikimedia.org/T109237 [17:25:01] FlorianSW: our release cadence isn't that tardy. the patch will make it out in due time :) [17:25:23] ok, nevermind, I'll write that to the user. [17:25:37] dbrant: sometimes you write tasks in your heart but forget that you also wrote them in phabricator [17:25:40] do you know, when the next prod release (of course: with the fix) will be released? [17:25:51] FlorianSW: yes, we can. that doesn't make it a good idea, though. It would mean the build would not be easily reproducible for others [17:26:40] bearND: fair point. That's why (maybe) it's a good idea to have release branches to cherry pick fixes for a beta release where a user found a problem :P [17:26:53] FlorianSW: i don't mean to be dismissive. it's nonzero overhead to cut a release so we want to make it worthwhile. if we didn't do any testing then it would be easy. for some background, here's our "quick" 25 step release process for a beta https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Release_process#Beta_release [17:32:38] niedzielski: wouldn't it be possible to add one more step where you simply create a new branch from the commit where you build the app? :) Btw.: mediawiki/core and extensions isn't an easy release, too (I assume), and they've release branches, too. And even if cherry picks are easier to deploy in web (so release branches makes more sense, maybe), they know why they do the work :) [17:33:30] FlorianSW: making a branch is simple but testing takes time. we're working to build out our automations but it's slow going [17:33:57] FlorianSW: and we do tag releases, it would be easy to branch off one [17:37:20] niedzielski: https://phabricator.wikimedia.org/T109237 looks more general. I think that by now all is fine more or less with images transitions [17:37:53] niedzielski: it's only that initial click... I will add screen recording to that ticket [17:41:08] kaity_: can you take a look at my comments in https://phabricator.wikimedia.org/T124836? [17:41:23] etonkovidova: thanks. on my trackfone, i think it's on every click. [17:41:54] niedzielski: interesting [17:42:09] kaity_: and my comments on T104491 :) [18:00:24] is it bad that I just tried to join our standup hangout because I completely thought it was Thursday...? [18:01:27] jhobs: i was going to join it anyway [18:01:31] and read my notes aloud [18:01:37] boom [18:01:38] let's do it [18:01:48] in the most dramatic of fashions [18:15:37] looking for headphones for standup, one sec [18:16:39] k [18:22:10] well [18:22:18] jhobs and i had a wonderful standup [18:22:40] yes, with not even enough time left to triage [18:34:22] niedzielski: dbrant bearND mbinder how bad is it w/o headphones on my end? wondering whether i should spend time trying to hunt them down or keep doing actual work [18:34:43] mdholloway: fine for me [18:34:58] mdholloway: there wasn't any echo today as far as i could tell [18:35:01] mdholloway: it's not bad, so don't worry about it for today [18:35:06] ok cool, thanks [18:38:24] bmansurov: I just read your email reply on the pushipedia thread and started laughing hysterically [18:38:42] lol [18:39:10] bmansurov: also, I just replied to your comments on the upstream patch. Want to hash out any further confusion/discussion here before I upload a new PS to save time? [18:39:27] or hangout would work as well [18:39:29] let me take a look, jhobs [18:40:10] jhobs: it doesn't have to be inside in order to stub [18:40:14] you can put it outside [18:40:29] bmansurov: how will I access the method then? [18:40:39] because right now I do mw.viewport. [18:41:02] but you never call makeViewportFromWindow do you? [18:41:21] no but I mean the stub asks for the module name and method name [18:41:37] and if the method is outside, how will it have access? [18:41:48] you're right [18:42:01] mabad [18:42:11] no worries :) [18:42:38] I figured there was just as much chance I was wrong since I haven't written many wmf test suites before [18:43:11] jhobs: so everything looks good except for the formatting part [18:43:16] ok cool [18:43:22] also i'd just use height(), but it's up to you [18:43:54] bmansurov: I wouldn't be particularly opposed to it, but since the other library has much more extensive use and testing behind it, I'd rather defer to their judgment [18:44:03] ok [18:44:29] alright I'll upload the new PS with just the formatting then and hopefully this'll finally be done [18:45:04] niedzielski: hey, thanks for the comments. to address one, yeah, dropping uselang is intentional -- it turns out that targeting the wiki language (which is the default behavior without uselang) is an official Zero policy [18:45:28] niedzielski: working on the other two now. [18:46:56] jhobs: +1 from me guaranteed ;) [18:47:45] mdholloway: woo! consider adding that to the commit message :) [18:50:41] niedzielski: will do! [18:50:57] 👍 [19:11:27] bearND: mbinder: niedzielski: dbrant: rejoining in a sec. sorry if i disconnect again, i keep getting booted today for some reason [19:31:37] coreyfloyd: retro [19:31:47] nzr: retro [20:15:10] jhobs: I'm driving through Virginia again! /me waves [20:16:44] * jhobs waves to kristen [20:33:58] yurik: awesome, thanks! [20:35:33] mdholloway, hehe, i have had that problem many a time [21:01:59] bearND: estimation [21:50:03] dbrant|brb: niedzielski: bearND: I have one or two miscellaneous things to add in the Zero stuff but they're related to items under discussion in T115398 and therefore a little more tentative. so i'm thinking of putting them in separate follow-up patches. Does that make sense or should I keep updating the main patch currently under review? [21:50:15] i'm wary of holding up the bulk of the work [21:51:00] mdholloway: in general, distinct patches are better than monolithic. as long as the current patch doesn't break anything, then i say keep them separate [21:51:16] niedzielski: sounds good.