[08:58:09] morning [09:22:15] hey joakino [10:02:03] o/ joakino, phuedx [10:02:24] hi bmansurov [10:02:28] ! [10:07:56] hey bmansurov [10:11:09] joakino: gonna get mocha running some tests for loot [10:11:27] after writing up the notes i have about the extraneous transforms [10:12:16] phuedx: great! I found the comments very helpful with why you did what you did, so thanks [10:15:05] some Tchaikovsky today https://www.youtube.com/watch?v=FqZfoK25lnY [10:15:13] (yes, i had to copypasta the name) [10:16:49] some tangled thoughts of leaving today: http://music.tangledthoughtsofleaving.com/album/yield-to-despair [10:18:41] the album is as dark and gloomy as the name and artwork suggest [12:20:17] breaking for lunch [14:06:56] afk for a little while [14:06:57] packing [15:33:13] jdlrobson: i poked at you in the github comments, the webpagetest links were for different urls (the no images had less transforms than the w/ images) [16:26:28] I think that https://phabricator.wikimedia.org/T120756 could be satisfied by Gather on desktop. What do you folks think? [16:27:01] * bd808 knows that the backend bits of Gather may need some work to scale to all platforms [16:29:02] yes, gather is perfect for this use case [16:29:53] That task is one of the things on the 2016 EU hackathon wish list [16:30:17] already done ;) [16:35:15] phuedx: you around? [17:18:08] Hey phuedx so let me try and explain the webpage test stuff better. So the thing I'm trying to show is that https://reading-web-transforms.wmflabs.org/benchmarks/loot/Barack%20Obama?transforms=nodatamw vs ttps://reading-web-transforms.wmflabs.org/benchmarks/loot/Barack%20Obama?transforms=noimages|nodatamw [17:18:34] You'd think the latter performs much better than the former but for some reason I'm finding that not to be the case... In fact the opposite [17:19:28] Bytes go down obviously but first paint seems to go up which is super odd [17:35:26] phuedx: the perf team advised using best values, so what i'm comparing is http://www.webpagetest.org/result/151222_KK_14JR/9/details/ vs http://www.webpagetest.org/result/151223_K0_2W2/6/details/ [17:35:46] Start render of 41.961s for just nodatamw [17:36:01] Start render of 65.574s for nodatamw and noimages [17:36:26] i've repeated the test and got similar results and it's doesn't make much sense. Images don't seem to be having the impact they used to for whatever reason.. [17:48:08] phuedx: are you standing with us... [17:48:14] ...or against us? [17:48:14] not with you [18:04:10] etonkovidova: mdholloway kaity bare bones standup again. Any interest in skipping? Or maybe use the time for something else? [18:04:27] jdlrobson: tracy island REAL quick [18:04:55] phuedx: jdlrobson imma lurk in on that if you guys don't mind cuz l00t is interesting [18:05:07] go [18:05:08] for [18:05:08] it [18:05:15] phuedx: coming! [18:05:34] mbinder: etonkovidova: kaity: yeah i'm up for whatever. the only thing i wanted to ask, max, should we put a story point on https://phabricator.wikimedia.org/T121909? [18:05:54] mbinder: I am ok to skip standup :) [18:10:40] mdholloway: it's tricky to estimate something after it's been done. priori knowledge vs posteriori knowledge, and all that. ;) It's also a little odd to estimate without the rest of the team. [18:11:11] mdholloway: The point of estimation is to understand longterm capacity, not use it as a measure of credit. We could give it points if we think it will help us understand our future capacity better. [18:12:05] mdholloway: If there is a chance it will confuse our knowledge of future capacity (moreso than leaving it be) then we ought to leave it be. [18:12:25] mbinder: i'm cool with leaving as is. [18:12:35] mdholloway: by now, I imagine I've philosophized you out and it'll just be ignored :) [18:14:45] mbinder: no way! it was a pretty minimal task anyhow, so i don't think it makes much difference either way. [18:15:47] mdholloway: can you please remove me as an auto-reviewer in gerrit for the mobile content service? [18:16:50] as much as i want to play a role, i never had enough bandwidth to help maintainer the service, and it's just cluttering my inbox at this point [18:17:20] mdholloway: 👍 Also, I was thinking, do we want to do grooming today? We could get together with etonkovidova and comb through the bug backlog. Or we could use the time to get some long-postponed 1:1 time. :) [18:19:30] bgerstle: sure, makes sense. i'll take you off. coreyfloyd / mhurd_afk, do you guys want off the content service auto-reviewer list too, or want to stay on? [18:20:14] mbinder: sure, i could do some grooming/shooting the breeze :) [18:21:02] mdholloway: thanks. hopefully i'll be asking you to re-add me soon ;-) [18:21:12] @seen jminor [18:21:19] mbinder: does JoshM have something on android? if we do android triage back log JoshM or dbrandt should be present? [18:22:17] etonkovidova: Josh is only iOS. I think michael can help identify obvious candidates for closure, and we can always just comment in dmitry for final review. [18:23:10] mbinder: ah :) ok then [18:25:48] phuedx: incidentally, you can combine the Array.from and Array.map calls in that paste ;P https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/from [18:28:17] bgerstle: i took you off the auto-reviewer list. it's at https://www.mediawiki.org/wiki/Git/Reviewers if you want to re-add yourself in the future. (i wanted to find that page again myself since i didn't have it bookmarked before.) [18:28:45] bookmarked, thanks mdholloway [18:29:02] it will be a miracle if i'm actually able to remember i bookmarked that, but we'll see :-P [18:43:12] Volker_E: there? [18:43:22] jdlrobson: yup [18:43:24] the 720px is what mobile is switching too [18:43:32] i'd rather not do two changes given no one has adopted it [18:43:35] it just confuses things [18:43:42] jdlrobson: so there was a longer discussion around that [18:43:50] the comment about landscape makes sense though [18:44:14] jdlrobson: I ran in previous projects in several stupid side-effects on some weird devices [18:44:23] Well the logic for choosing 768px was "what is an iPad mini?" [18:44:34] I know because I made it [18:44:48] So I don't see the issue with switching to 720px now that we know there are tablets with that many pixels [18:44:50] jdlrobson: as I said in one of the comments, 768px is very common [18:45:27] just sounds like we're making this more complicated then necessary.. all i want right now is a central place to hold this number and in mobile it's gonna be 720px. [18:45:29] jdlrobson: yeah, but you have phablets and stuff, where 720px might kick in although not wanted [18:45:43] well let's expose those bugs then? [18:45:53] we can either stall and do nothing or do something and then react with new information [18:46:12] the only data point i have right now is there's a device with 720px width that serves a mobile design on a big screen [18:46:31] i'd hope for more data points as we tweak it so the number is just not plucked out of nowhere based on the iPad device width [18:46:58] the great thing about having this number is you can fix it in one place !! [18:47:18] jdlrobson: Ok, well, then let's put this discussion in a phab ticket as it's an important one [18:48:02] jdlrobson: there's so many devices and we should know where we put the boundary and why [18:48:12] Volker_E: it's documented in the patch no? [18:49:03] but it's just one data point and setting the breakpoints is a big deal UX-wise IMHO [18:49:33] Volker_E: "Number is prone to change with new information." [18:51:03] Volker_E: actually deviceWidthTabletPortrait doesn't make sense [18:51:27] as all we care about is a break point to switch to the tablet styles [18:51:33] YAGNI [18:52:21] jdlrobson: I'd love to see that not just in a comment above the actual number, but in a task, where we collect (many) 'data points' (devices) and the decisions around to make that searchable for future developers looking for answers [18:52:47] why? That's what commit history is for? [18:54:30] jdlrobson I personally don't find commits (& Gerrit's interface) as great for discussion as Phabricator [18:54:38] jdlrobson: but that might just be myself [18:55:07] each to their own... we have wikis too. There's too many places. Code is the most reliable jumping off point. [18:55:21] jdlrobson: think tabular data of device widths [18:55:52] jdlrobson: as I said, breakpoints are a big decision for design [18:56:28] well it's already changed in Minerva the main user of this [18:56:40] so changing it to 768px makes no sense as there would be no consumers [18:56:58] jdlrobson: why is that? [18:57:04] so all this does is allow the status quo of having no breakpoint defined to continue [18:57:12] and people inventing their own numbers [18:57:29] just like 768px was defined by an engineer :) [18:59:42] jdlrobson: Side note: In big projects we've came up with different UI with more breakpoints like smartphone, smartphone-landscape, tablet, tablet-landscape, desktop, widescreen [19:00:38] jdlrobson: we didn't use the differentiation all the time, but in some special occasions, we had the breakpoints to address certain issues on a landscape-orientation vs portrait [19:01:53] also, I've seen devs using `-portrait` as label, might be a non-English-speaker idea on what a breakpoint actually means and how you say it correctly :P [19:02:05] sure, but we're not a big project in terms of developers and right now we have no official breakpoints. Merging this patch will give you a breakpoitn and allow you to control these sorts of things going forward. Delaying it is just making your job harder on the runtime. It's trivial to change a number (it's a pain in the arse to go through existing css rules [19:02:05] and change them to use the thing in core). [19:02:11] trust me on this :) [19:02:35] jdlrobson: I see that and I trust you [19:03:47] jdlrobson: for the mid-term I'd wanna see data-driven exchange of ideas on Phabricator and/or MediaWiki about the decisive process around breakpoints [19:04:29] and i agree and i'm hoping that will be part of a style guide and shared mixin/variables file [19:04:33] but we're a long way from that :( [19:08:21] jdlrobson: added a comment and removed my -1 [19:09:51] i suspect this is gonna be one of those patches that lingers for some time as other teams don't know they need it yet [19:44:22] Does anyone have tips to debug LESS in Chrome? [19:46:20] OH-: less translates to css, and you can debug css using dev-tools [19:46:52] I found the issue in CSS, but I'm too inept to find it in LESS :L [19:52:21] nevermind, I think I found it :P [20:03:04] jdlrobson: jkatz are you joining? [20:12:54] jdlrobson: you free? [20:16:06] arrgg [21:00:05] OH- if you found the selector that is carrying the property you want to change, search for the most outer right selector in the Less files [21:01:00] so if the rule is `div#example1 > #example2 .example3` search for .example3 in the Less files [21:01:37] OH- it's one of the easier ways [21:27:36] FlorianSW|away: it's funny that switching to notifications in core means we now have a mw-notification-area on every page view which i seem to remember was the concern with the mobile code haha :) [21:28:48] jdlrobson: I metioned that too and added it to my own "note list" :P That shouldn't be the case, iirc, but I haven't the time to check it now :/ [21:30:03] FlorianSW|away: :-) [21:30:09] just finished reviewing your patches [21:30:28] im not touching any extension.json patches until we pull out Minerva :) [21:30:52] thanks! :) Could you open a bug for the notifications thing and add me as a subscriber? Then I can delete it from my own list and someone else could (possibly) take a look, too. [21:31:25] sure [21:31:41] jdlrobson: I think that's not very good :/, it just takes longer to create extension.json in MobileFrontend (it already took more time as I thought) :) [21:33:23] FlorianSW|away: https://phabricator.wikimedia.org/T122356 [21:33:32] FlorianSW|away: a large extension.json is not useful either [21:34:24] i'd rather we created more mess and confusion at this stage. Especially given porting it out seems pretty straightforward to me (if people can review my open patchsets asap :)) [21:34:36] if they don't happen before next deployment i worry they will not happen :/ [22:42:30] mhurd, are you around? Can you tell me if you managed to solve the issue of the language codes -> language name ? [22:42:50] * mooeypoo is running into a similar issue [22:46:32] jhobs: you seem stuck on that card? Don't be afraid to ask for help if that's true :) [23:04:37] mooeypoo: oh, i think for the lang names we can ask the sitematrix api - see example queries on description of this ticket: https://phabricator.wikimedia.org/T121128 [23:06:10] mhurd, interesting... Isn't that what CLDR is doing too? [23:06:26] mooeypoo: hmm not sure [23:07:32] mhurd, I'll look into that. Thanks! [23:07:50] mooeypoo: yw! hope it work for you :) [23:07:56] *works* [23:08:30] I'll keep you posted if I find anything better, since I'm dealing with a similar issue with Echo. I'm off for the evening (last eve with parental units before I come back to SF) -- have wonderful holidays :)