[09:44:43] 3MediaWiki-extensions-GWToolset, Multimedia: GWT seems to be currently broken - https://phabricator.wikimedia.org/T87040#990835 (10dan-nl) @Tounoki, you should be able to run a small test on beta first. if your test works on beta, then “in theory” it should work on production once GWToolset 0.3.8 (1fd5c4d) 16:55... [10:41:27] 3MediaWiki-extensions-MultimediaViewer, Multimedia: "VIew in browser" link in download panel overflows - https://phabricator.wikimedia.org/T87427#990869 (10Namit) 3NEW [12:09:59] 3MediaWiki-extensions-GWToolset, Multimedia: GWT seems to be currently broken - https://phabricator.wikimedia.org/T87040#990934 (10Bawolff) Assuming procedure hasnt changed, generally you cherry pick the patch to current wmf branch, have someone with deployment rights +2 that, then create a patch against wmf bra... [12:12:40] 3MediaWiki-extensions-GWToolset, Multimedia: GWT infinite loops with wmf's new hhvm job runners - https://phabricator.wikimedia.org/T87040#990935 (10Bawolff) [12:48:28] (03PS5) 10Gerrit Patch Uploader: Apply coding conventions for JavaScript [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/184383 [12:48:30] (03CR) 10Gerrit Patch Uploader: "This commit was uploaded using the Gerrit Patch Uploader [1]." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/184383 (owner: 10Gerrit Patch Uploader) [13:36:07] 3MediaWiki-extensions-GWToolset, Multimedia: GWT infinite loops with wmf's new hhvm job runners - https://phabricator.wikimedia.org/T87040#990987 (10dan-nl) @Bawolff, would you mind setting that cherry picked merge up? i sent an email to the glamtools mailing list letting everyone know about the issue and asked... [15:16:21] (03CR) 10Gilles: [C: 032] Apply coding conventions for JavaScript [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/184383 (owner: 10Gerrit Patch Uploader) [15:17:26] (03Merged) 10jenkins-bot: Apply coding conventions for JavaScript [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/184383 (owner: 10Gerrit Patch Uploader) [15:30:16] (03CR) 10Gilles: [C: 032] Match size of preview and real image [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) (owner: 10Phoenix303) [15:30:19] (03CR) 10jenkins-bot: [V: 04-1] Match size of preview and real image [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) (owner: 10Phoenix303) [15:54:05] gi11es: Move it earlier, not later [15:54:12] I have a flight at 15:00 that day [15:54:38] So I'll basically be gone at 12:00 [16:52:35] marktraceur: http://jscomplexity.org/ https://github.com/philbooth/jscomplexity.org [16:54:24] Neat [16:54:32] And qunit has something called completeness test [16:54:37] Running it now [17:00:29] Not sure how I can get this to run on only UW tests and code. [17:03:50] Maybe set up a test runner for UW locally... [17:15:46] Hrm [17:15:51] Not sure if this will work very well [17:17:03] The dependency management is all stuck in MediaWiki, which is cool and all, but it means I'd need to recreate that dependency tree in the configuration for the qunit runner [17:26:24] are you talking about qunit or that js completeness thing? [17:27:36] Uhh, both [17:27:45] gi11es: Not the complexity thing [17:27:49] well, completeness test is already in our qunit [17:27:53] just tick the box on the qunit page [17:27:55] Soooort of. [17:28:06] gi11es: It tests completeness for *all* of the MediaWiki code [17:28:33] So if mw.uw.controller.Deed.test.js doesn't test mw.Api.getCategories, then we're out of luck. [17:28:52] And I can't group together all of the UW tests, because our qunit interface is Silly [17:29:05] I think there's a filter parameter [17:29:39] Oh? [17:30:12] But our test modules aren't named consistently either... [17:31:04] ?filter= and ?module= [17:31:51] filter=uw should do the trick [17:32:10] Only for the controllers, models, and new UI classes [17:32:29] mw.UploadWizard.js, mw.fileApi, mw.DeedPreview.js [17:32:52] -.js [18:10:53] gi11es: I might just write a plugin that can pull our dependencies out of the PHP files somehow... [18:11:08] That way we could run qunit tests outside of mediawiki too. [18:13:18] "just" [18:14:25] Especially since the filter param doesn't work very well, and we'll get better reports from karma [18:16:26] gi11es: If you think it's worth me spending time on this, that is. If not we can use the pretty lackluster completeness report. [18:16:34] And I can run the complexity report thing next [18:17:00] yeah let's not spend too much time on that now, as long as you can compare a before/after figure that tells a story for completeness it's fine [18:24:39] KK [18:25:07] Argh [18:25:11] More rescheduling [18:25:16] Now I can't go to SoS [18:31:09] gi11es: Before: "Detected calls to 113/166 methods. 54 methods not covered" After: "Detected calls to 120/168 methods. 49 methods not covered" [18:31:18] 3MediaWiki-extensions-GWToolset, Multimedia: GWT infinite loops with wmf's new hhvm job runners - https://phabricator.wikimedia.org/T87040#991285 (10greg) @bawolff will you be in town for the Dev Summit? I'd like to fix this as soon as possible. I haven't had a chance to look into the fix needed, but if it can b... [18:31:41] thanks [18:31:43] Not super helpful report, I think...we must have more than 166 methods, and most of the report has to do with mmv or core [18:32:26] maybe the complexity one will be more interesting [18:32:33] Probably [18:32:50] Ugh, it's a web form...this should be interesting [18:33:02] yeah but the source code is available [18:33:18] I guess if you concatenate all the JS files it should do the trick [18:34:59] Suppose so [18:35:03] * marktraceur will do that [18:38:04] 3MediaWiki-extensions-GWToolset, Multimedia: GWT infinite loops with wmf's new hhvm job runners - https://phabricator.wikimedia.org/T87040#991312 (10Gilles) @greg he won't: https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015/Attendees [18:38:29] Hm, I'm not sure if that worked very well [18:38:40] I think it's saying it's more complex [18:39:59] Hm [18:40:25] More lines of code, and slightly less complex on average (complexity / LOC), but more complex overall [18:40:39] Very slightly more maintainable (practically negligible) [18:40:51] What have I been *doing* with my life [18:41:17] That said, our maintainability is pretty high [18:41:47] And I think each individual file is better, but the whole codebase got bigger [18:56:32] interesting [18:57:18] the page says things about measuring interconnection between functions, etc. it would be interesting how much of that is working with our style [18:57:31] i.e. is it really finding all the connections it should between functions and their usage [18:57:31] Probably relatively little [18:59:32] I think the metrics are all pretty stable across our code [18:59:40] So something might be going sideways in the analysis [19:01:14] Also, "mean parameter count" is above 50 for most files I've tried, above 80 for a lot [19:01:18] I think that's vastly wrong [19:02:34] 3MediaWiki-extensions-GWToolset, Multimedia: GWT infinite loops with wmf's new hhvm job runners - https://phabricator.wikimedia.org/T87040#991391 (10Bawolff) I set up cherry picks for the two commits in question. See https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions/GWToolset+branch:wmf... [19:06:53] 3MediaWiki-extensions-GWToolset, Multimedia: GWT infinite loops with wmf's new hhvm job runners - https://phabricator.wikimedia.org/T87040#991393 (10greg) >>! In T87040#991312, @Gilles wrote: > @greg he won't: https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015/Attendees :( :( @gilles, can you shep... [19:07:44] (03PS3) 10Phoenix303: Match size of preview and real image [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) [19:19:00] gi11es: Do you want me to look at any different angles for the complexity or coverage things, or should I carry on with other things? [19:19:19] nah, we'll look at it another time [19:19:29] it seems like too much effort right now for 2 lines on a slide [19:19:30] KK [19:19:40] it was worth a shot [19:19:42] We can list qualitative improvements, though [19:20:18] Like "There are far fewer circular references to calling classing from child classes" or "We actually use inheritance now" or "There is a glimmer of hope for an MVC framework in UploadWizard now" [19:23:45] 3MediaWiki-extensions-GWToolset, Multimedia: GWT infinite loops with wmf's new hhvm job runners - https://phabricator.wikimedia.org/T87040#991450 (10Gilles) Yes, this seems serious enough to do on the 8am SWAT on Monday. I'll add it to the Deployments page. [19:32:48] (03CR) 10Gilles: [C: 032 V: 032] Match size of preview and real image [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) (owner: 10Phoenix303) [19:34:03] 3MediaWiki-extensions-MultimediaViewer, Multimedia: Size of preview and real image does not match in MediaViewer - https://phabricator.wikimedia.org/T87295#991499 (10Gilles) a:3Phoenix303 [19:40:51] (03CR) 10jenkins-bot: [V: 04-1] Match size of preview and real image [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) (owner: 10Phoenix303) [19:44:44] 3MediaWiki-extensions-MultimediaViewer, Multimedia: Size of preview and real image does not match in MediaViewer - https://phabricator.wikimedia.org/T87295#991540 (10Tgr) >>! In T87295#989281, @Phoenix303 wrote: > I have looked upon this issue. What i can figure it out is that the metadatapanel "top" property ch... [19:46:47] (03CR) 10Gilles: [C: 04-1] "Seems like some test assertions need to be deleted as well" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) (owner: 10Phoenix303) [19:57:23] 3MediaWiki-extensions-GWToolset, Multimedia: GWT infinite loops with wmf's new hhvm job runners - https://phabricator.wikimedia.org/T87040#991573 (10Tgr) >>! In T87040#990835, @dan-nl wrote: > i don’t know yet how to “Prepare patches in gerrit against the current live wmfNN branches (or a subset if the bug is li... [19:59:35] (03CR) 10Gergő Tisza: [C: 031] "Virtual +2. I left a remark about what feels to me as easier-to-read code, but YMMV; feel free to merge." (031 comment) [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186160 (https://phabricator.wikimedia.org/T86609) (owner: 10Gilles) [20:20:39] (03PS4) 10Phoenix303: Match size of preview and real image [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) [20:24:20] (03CR) 10Phoenix303: "Thanks Gilles i have removed dependent assertions." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) (owner: 10Phoenix303) [20:33:11] (03CR) 10Gergő Tisza: "IMO this is both the wrong approach and the wrong place in the code." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186158 (https://phabricator.wikimedia.org/T87184) (owner: 10Gilles) [20:40:53] 3MediaWiki-extensions-MultimediaViewer, Multimedia: Browsing through previous/next images should not change the back button function - https://phabricator.wikimedia.org/T64167#991727 (10Tgr) [20:40:55] 3MediaWiki-extensions-MultimediaViewer, Multimedia: MultimediaViewer should not leave so many history entries when closed - https://phabricator.wikimedia.org/T64266#991728 (10Tgr) [20:41:38] 3MediaWiki-extensions-MultimediaViewer, Multimedia: MediaViewer should not change the page title when opening an image - https://phabricator.wikimedia.org/T75347#991730 (10Tgr) >>! In T75347#764203, @Gilles wrote: > We're planning on user testing different history strategies at some point in the future, I'll mak... [20:49:11] Hm, interesting. My local Chrome fails the browser tests on the tutorial step, not the upload step [20:56:23] (03CR) 10Gilles: "I think it's premature to move something to EL core before it's gone through the motions and been used. Just look at how we're still chang" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186158 (https://phabricator.wikimedia.org/T87184) (owner: 10Gilles) [20:58:08] (03CR) 10Gilles: "recheck" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) (owner: 10Phoenix303) [20:59:08] (03CR) 10jenkins-bot: [V: 04-1] Match size of preview and real image [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) (owner: 10Phoenix303) [21:17:15] (03PS7) 10Gilles: Variant logging [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186158 (https://phabricator.wikimedia.org/T87184) [21:18:18] (03CR) 10jenkins-bot: [V: 04-1] Variant logging [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186158 (https://phabricator.wikimedia.org/T87184) (owner: 10Gilles) [21:18:51] gi11es: what are the things Pau said? [21:20:29] that it'd be better if it was sticky for a given user for a while, that we also need to track when people skip the image before it's loaded and that ideally it would only target new users, or I guess that we should record whether that's a new user or not to let us see if the trend is different for established users vs new users [21:21:04] the logic being that there's no "change effect" for new users, and there can be for established users [21:21:22] and if we don't A/B test for long enough or make it sticky for long enough, the novelty effect might skew the results [21:21:40] I might be forgetting something else, but I think that was the bulk of it [21:22:22] makes sense [21:22:35] the whole "is it a new user?" thing feels like a task of its own [21:22:52] yet another thing that could end up being useful for all EL tracking, I guess [21:22:52] I don't think that really affects how such a feature should be done in core though [21:23:06] (03PS5) 10Phoenix303: Match size of preview and real image [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) [21:23:06] I made a sketch in https://phabricator.wikimedia.org/T87459 [21:23:21] this whole thing isn't on our quarterly goals [21:23:26] it's just something I did on the plane [21:23:34] let's keep it like that, otherwise it's going to eat all our bandwidth [21:23:51] media viewer is in maintenance mode [21:24:33] I think it's a really bad pattern that ten different teams do ten quick hacks which together take more time than a proper solution and don't work as well [21:25:53] working on this in core would exactly mean that there is less time spent on MediaViewer and more on something that is generally useful and could be considered on the platform side in platform vs features [21:26:09] it's not part of our goals [21:26:12] we're not the analytics team [21:26:47] then why do it at all? experimenting with the blur effect is not part of our goals either [21:26:58] because I had some free time on the plane? [21:27:21] you're taking something I did on the side and turning it into a big thing [21:27:39] with the current way teams are set up in Wikimedia, feature teams need to take responsibility for supporting some of the core features they need for their work, IMO [21:27:46] it's fine as a side experiment and it could give us interesting data [21:27:58] sure, but when we're focusing on media viewer [21:28:00] which we're not [21:28:11] no, then we are focusing on analytics [21:28:31] which will be just as useful for UploadWozard or whatever [21:28:47] and for many other teams if done well [21:29:06] there's no shortage of great things we could do for the organization but we've committed to a specific list for this quarter [21:29:31] if we get distracted every time something like that comes by we'll miss all our agreed targets, which are higher priority [21:30:14] then lets push back the blur experiments to the next quarter and do them properly [21:30:26] the only reason I did this is because it seemed like a good idea and not something that we even have to do ourselves, it can help all the stalled tickets blocked by "we can't user test this" by giving them a direction [21:30:39] we really should break out of the "we don't have time to do it properly so let's do it badly" pattern [21:31:25] this isn't done badly [21:31:33] it's just not done in the very high standards you have [21:31:40] it does the job, it's well documented [21:31:49] it just puts the burden of reusability on the next person who needs it [21:31:54] instead of the person who writes the first version [21:32:32] it's not that big a deal, if another team comes by and is interested in doing the same thing, why couldn't they deal with abstracting it? [21:33:14] same reason you did not abstract what, say, the growth team did [21:33:17] if it was submitted by a random volunteer we wouldn't tell them "this works perfectly, but please wait 3 months for us to rewrite it in a generic manner before we collect a single point of data" [21:33:40] I sure would :) [21:33:45] it's counter-productive, depending on the data this collects it could unlock 2-3 tickets right now [21:34:08] not if the data collection is urgent or important, but it is neither in this case [21:34:25] it's not urgent, but the only thing blocking it is imaginary [21:34:59] 3Multimedia: Change browser tests for skip preference to use login redirects - https://phabricator.wikimedia.org/T87462#991812 (10MarkTraceur) 3NEW a:3MarkTraceur [21:35:06] there's no immediate demand for this feature by other teams, so why wait for it to be abstracted? [21:35:41] what I am trying to say is, I guess, we should disallow reimplementing missing core functionality in products, because that creates the right incentive for us to make a great analytics foundation [21:35:53] you're getting wrapped up in programming ideals and the bottom line, improving the experience for users, is delayed for no reason [21:36:00] if that incentive is not there, it is simply not going to happen [21:36:23] and we will all lose out big time in the long run [21:37:24] it's not realistic to just expect the Analytics team to provide a great framework for us, IMO, with their current size and workload [21:37:43] feature teams need to pick up some of that responsibility [21:38:15] we're even smaller than them, it's unrealistic for us to stop at the first thing like that which comes our way [21:38:15] and we have seen in the past that if we let us remove the need by doing hacks, then it's simply not going to happen [21:38:29] we say we'll get back to it and do it properly, and then we never [21:38:40] that's an issue that has absolutely nothing to do with this changeset [21:38:52] go complain to managers about that, don't stop progress for those reasons [21:39:21] I live in the reality of limited resources, which means not jumping on needless non-urgent homework that comes our way when we're under capacity for what we really need to get done [21:40:15] so schedule it for next quarter [21:40:36] it doesn't even register in the grand scheme of multimedia priorities [21:41:22] basically the argument is that this is not important so we should spend just a little time to do it properly instead of spending a lot of time to do it right [21:41:32] I don't think that makes sense [21:41:55] if we want to stick to priorities that strictly then don't do it at all [21:42:08] it makes sense to treat this as a free time contribution, which it is, and as such not reshuffle anyone's priorities because of it [21:42:14] why block it? it works [21:42:22] otherwise, collect time to do it properly [21:42:57] if instead of doing ten things as a quick hack, we would do one thing properly, MediaWiki would be a better place [21:43:38] this is not a quick hack, it follows all our standards [21:43:48] it just doesn't live up to your reusability ideals [21:44:03] it's exactly the same quality as all the tracking we're already doing [21:44:14] I guess the issue I really want to complain to management about is that feature developement is overprioritized to the expense of "feature developemenet support features" [21:47:07] even in the context of reusability you're making assumptions about the existing need [21:47:23] which other team has a deployed product they would like to test variants of right now? [21:47:39] I think most other teams are too busy launching a version of a product at all [21:48:29] looking at the issue from our perspective, if we needed something that belonged to another team's extension, I know that we would have no problem doing the work necessary to abstract it to core ourselves [21:50:07] sidetrack: where should we keep the documentation about the possible values of a pseudo-enum field in the EL schema? [21:50:24] should I make a talkpage template for that? [21:50:27] nowhere, it's not an enum anymore and documentation goes stale [21:50:58] it only goes stale if we let it [21:51:01] it would make sense to document it where the values originate from [21:51:10] but not on a seperate medium [21:51:44] as long as we can make sure it can be found from the schema page, that works [21:52:19] but then you have to deal with external links to the code going stale [21:52:57] I would go with the talk page and maybe putting a mention in the logger class that it will have to be updated [21:57:10] although I guess we can just put a mention to update the link at that point [21:57:42] so how about putting https://doc.wikimedia.org/MultimediaViewer/master/#!/api/mw.mmv.logging.ActionLogger as the description and updating the jsdoc so that it shows up there? [21:59:03] looks like jsduck can permalink property declarations: https://doc.wikimedia.org/MultimediaViewer/master/source/mmv.logging.ActionLogger.html#mw-mmv-logging-ActionLogger-static-property-logActions [21:59:30] so just put that in the EL schema description? [22:10:06] (03CR) 10Gilles: "recheck" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) (owner: 10Phoenix303) [22:10:23] yeah sure [22:11:10] (03CR) 10Gergő Tisza: [C: 04-1] "https://meta.wikimedia.org/wiki/Schema:MediaViewer is not very helpful the way it is, it should be possible to find your way from that pag" (031 comment) [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186158 (https://phabricator.wikimedia.org/T87184) (owner: 10Gilles) [22:16:04] (03CR) 10Gilles: [C: 032] Match size of preview and real image [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) (owner: 10Phoenix303) [22:17:00] (03Merged) 10jenkins-bot: Match size of preview and real image [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) (owner: 10Phoenix303) [22:40:19] (03CR) 10Gergő Tisza: "Resizing the image got a little jerkier this way (not a problem, just noting) so maybe that's why the max-* was there? Makes me a bit anxi" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186212 (https://phabricator.wikimedia.org/T87295) (owner: 10Phoenix303) [22:57:45] (03PS4) 10Gilles: Collect thumbnail width in the performance log [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186160 (https://phabricator.wikimedia.org/T86609) [22:58:02] (03CR) 10Gilles: Collect thumbnail width in the performance log (031 comment) [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186160 (https://phabricator.wikimedia.org/T86609) (owner: 10Gilles) [23:02:56] (03CR) 10Gergő Tisza: [C: 032] Collect thumbnail width in the performance log [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186160 (https://phabricator.wikimedia.org/T86609) (owner: 10Gilles) [23:04:22] (03Merged) 10jenkins-bot: Collect thumbnail width in the performance log [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/186160 (https://phabricator.wikimedia.org/T86609) (owner: 10Gilles) [23:13:09] (03CR) 10Gergő Tisza: Use promises for getting image info (031 comment) [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146604 (https://phabricator.wikimedia.org/T51988) (owner: 10MarkTraceur) [23:14:36] 3Analytics, MediaWiki-extensions-MultimediaViewer, Multimedia: Collect more data in MediaViewer network performance logging - https://phabricator.wikimedia.org/T86609#992060 (10Tgr) [23:47:34] (03CR) 10Gergő Tisza: [C: 04-1] "Don't know if it is related to this patch specifically, but the "Upload more files" button in the success step is broken." [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146604 (https://phabricator.wikimedia.org/T51988) (owner: 10MarkTraceur) [23:48:00] tgr: In master? [23:48:10] Or no. [23:48:15] Scared me there [23:48:44] haven't tested in master [23:49:08] should I? I recall you and gi11es discussing this, thought it might be a known issue [23:49:37] It's happened a few times recently because I've been mucking with resetting the interface and storing state in different places [23:49:44] But I fixed patches before they got merged [23:52:52] yeah, can't reproduce on beta Commons [23:53:05] I guess the patch is just based on the wrong revision [23:53:09] K [23:53:23] (03PS16) 10Gergő Tisza: Use promises for getting image info [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146604 (https://phabricator.wikimedia.org/T51988) (owner: 10MarkTraceur) [23:57:27] (03CR) 10Gergő Tisza: "Can still reproduce, so something in this patch must be breaking it." [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146604 (https://phabricator.wikimedia.org/T51988) (owner: 10MarkTraceur)