[00:00:05] marktraceur: Check the math on the spreadsheet, I think it is correct. [00:01:29] marktraceur: But please do this AFTER you code review the zoom feature. That’s a much higher priority than arguing about percentages on the survey. [00:31:28] Ugh [00:31:45] tgr: Now we're hardcoding the spinner URL from upload.wikimedia.org? [00:35:27] * bawolff awaits some trollish admin to delete the file ;) [00:36:26] No, that won't matter, because that's not how we're doing this. [00:36:42] There is a way to include media in an extension, and linking to an upload.wikimedia.org thumbnail is not it [00:38:59] Hmm, someone should make all paged media handlers extend a common base class... [00:39:16] bawolff: Thanks for volunteering! [00:39:24] eh, well [00:39:36] marktraceur: :) [00:39:55] I am hoping this zoom hack won't live long enough to be worth creating an asset for [00:40:52] tgr: In the meantime non-WM reusers send clients to our servers unnecessarily [00:40:57] Hi marktraceur : I just tested the zoom feature in Vagrant, with a bit of help from tgr. It generally worked well for me. I did not see the spinner while the image was loading, but I do not see that as a showstopper for tomorrow’s launch. [00:41:19] marktraceur: I could live with that [00:41:35] Is it really that difficult to make it an asset? [00:42:02] all right, all right [00:42:15] I mean I could do it, if you're not worried about it [00:42:21] It's my paranoia, I should resolve it [00:43:07] no, I'll do, you are right about it [00:43:14] 'kay [00:43:37] I'll review the rest, I foresee no problems [00:44:18] i am wondering how much effort would it be to allow requesting multiple thumbnail sizes in imageinfo [00:44:39] because we are piling horrible hack on horrible hack because the lack of that [00:44:44] Probably not *that* much, but also probably more than is worthwhile now... [00:44:51] I think aaron was already thinking about it, though [00:46:47] * marktraceur rubs eyes [00:47:49] This will work, but "horrible hack" will haunt my dreams... [00:48:03] Let's fix this soon [00:48:38] agreed [00:49:06] I'm getting "mw.mmv.durationLogger is undefined" [00:49:27] I did too, had to clear the browser cache [00:49:32] Ah 'kay [00:50:00] Well, it's ugly, but it'll do [00:50:13] happened a couple times recently, seems like ResourceLoader is less aggressive about cache breaking in dev mode [00:50:27] Which is hilarious [00:51:38] fabriceflorin: OK, once tgr adds the image as an asset we're good to go, let me try to explain what I mean - out of the 1727 survey responses, a total of 85 people mentioned zoom as something they wanted, sound right? [00:53:59] Thanks, Mark. There were indeed 85 requests for a zoom feature, out of 414 requests total. That’s where the 21% number comes from. [00:55:13] It don’t think it’s appropriate to use the 1727 total response number, because only a portion of these included comments in their responses. [00:55:49] Well, but the massive majority who *didn't* want anything substantial is important. [00:56:27] The 5% who want zoom are dwarfed by the 76% who didn't make substantive comments about desired features [00:56:28] Sure, we are happy to report that many users did not post comments, but that’s a separate matter. [00:56:46] OK [00:57:41] fabriceflorin: I'm just a little wary of using those numbers, especially the 21% version, to drive development priorities [00:57:54] A little, it should be said, is not a lot, but still wary [00:58:11] In my view, we want to identify which requests were the most frequent, of all the requests we logged. The purpose of the percentage here is to help us prioritize the most popular requests. [00:58:17] Anyway, it's working out mostly for the best, so [00:59:36] fabriceflorin: Which is great! Having priorities be informed is always a good plan. But our priorities also include fixing UW, TMH, the image scalers, Swift, and many other critical components [00:59:39] These numbers are supported by independent observations by Keegan and other community laisons that zoom was the most frequent request in the onwiki discussions as well. [01:00:18] I'm not raising any concerns now, we seem to be on track, but we should keep these numbers in context [01:01:07] marktraceur: Sure, these priorities are only for Media Viewer, not for other projects. We are trying to balance out these other projects fairly, one third for each, as agreed. [01:01:13] *nod* [01:02:59] But I am glad that we addressed your concerns, and I will continue to be careful in how I present these numbers in our communications. As a result of this discussion, I already fleshed out the survey report to explain about how these numbers were calculated. [01:06:21] marktraceur and tgr : Could you guys make sure to merge the zoom feature on Beta tonight, so that we can get Pau and Gilles to look at it prior to our 10am design review? I would like to get their take on this implementation. For example, there is no ‘back’ button, so some users may get lost, not realizing that they are in a different tab. This could become an issue, and I would like to anticipate possible solutions in our design [01:06:22] meeting. [01:07:14] Sure. [01:07:27] Thanks, much appreciated :) [01:07:45] (03PS8) 10Gergő Tisza: Minimal zoom implementation [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/132133 [01:08:10] On it. [01:08:46] (03CR) 10MarkTraceur: [C: 032] "hacks on hacks on hacks" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/132133 (owner: 10Gergő Tisza) [01:09:23] Out of curiosity, how much more work would be needed to build on what we have and implement the basic zoom feature #505, if it becomes necessary? Would it still be 4 points, or have we already shaved off some points with the current implementation of the zoom link? https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/504 [01:09:25] (03Merged) 10jenkins-bot: Minimal zoom implementation [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/132133 (owner: 10Gergő Tisza) [01:09:30] yeah, I do wonder how quickly they will come back to bite me [01:09:56] of well, it should last for a week at least [01:10:42] I am not saying we should develop #504, I just want to know how many more points would be required if we needed to build it. [01:10:54] fabriceflorin: maybe half a point less, the icon and when to display it can be reused [01:11:29] tgr: Got it. So it’s still 3.5 points. Good to know, thank you. [01:12:37] tgr: I am glad we have the link solution now, because we couldn’t have gotten the basic zoom feature done in time for the big releases on English and German Wikipedias, which are the most likely to give us a hard time about this feature. [01:14:25] fabriceflorin: The question is, will they like this version or be more annoyed we didn't build it right? [01:15:34] I don’t think anyone will *love* this version. But it’s a lot better than not having the feature at all. And we’re giving them the same as what they had before. [01:16:23] Roughly, yeah [01:16:52] on a related note, dschwen finally got zoomviewer to work on toollabs :) [01:17:05] I bet you it will not be used all that often, judging from the clickthrough on the full-screen feature, which is only about 2% of image views: https://docs.google.com/a/wikimedia.org/spreadsheets/d/1NLSPp2Ze0ekwPQXzDCQo5D1t09mxk2Yj3hNYPzqbLoE/edit#gid=0 [01:17:06] http://tools.wmflabs.org/zoomviewer/index.php?f=Schmettau_Plan_de_la_Ville_de_Berlin_1750.jpg [01:17:31] fabriceflorin: Likely that that's a problem with discoverability, not an indication of lack of interest? [01:18:02] Eloquence: Ooh, tools.wmflabs.org/giant-black-screen [01:18:12] * marktraceur stubbornly using Gnash, I guess [01:18:14] eloquence: Yeah, that is beautiful. We tried linking directly to the Zoomviewer, but there were some issues doing this in our timeframe. [01:18:14] marktraceur, it's the Evil Flash Version [01:18:19] but there's an html5 one as well [01:18:23] Eloquence: But you repeat yourself [01:18:32] :) [01:18:55] marktraceur, re: fullscreen, from personal experience, usually the mmv display is big enough or I want to go to the truly full-size image [01:18:59] Yeah [01:19:13] Having the extra inch or so of screen isn't *all* that helpful [01:19:14] but occasionally for presentations and such the fullscreen is nice to have. especially because it really gets rid of all the cruft. [01:19:18] Yeah. [01:19:38] Hey guys, I would love to have a beautiful zoom feature. But I don’t see how we can do this and still stick to our plan, sadly. Let’s see what people think of our crude link version and take it from there. [01:19:56] oh cool, zoomviewer [01:19:57] fabriceflorin: http://en.wikipedia.beta.wmflabs.org/wiki/Lightbox_demo#mediaviewer/File:Swallow_flying_drinking.jpg [01:19:59] Forever to be known as the Crude Link Feature ;-) [01:20:04] should we use that insteadM [01:20:04] tgr: What was the issue with linking to the Zoom viewer instead of the original file again? [01:20:17] well the issue was that it didn't work at the time [01:20:47] Oh, yeah, I remember that it was down. Is it back up yet? [01:20:57] apparently [01:20:57] tgr: I don't see why we should rush about it...it can go out for next week [01:21:04] prominent inclusion of labs tools is generally frowned upon because they're not built for production load characteristics [01:21:16] I think down the road we'll want to integrate IIP-like functionality properly. [01:21:22] (IIP is the open source library used by zoomviewer) [01:22:41] OK, I think deploying the current version tomorrow makes sense, and we can discuss whether or not we can improve on this in this cycle once we get more community members to think about these issues. [01:23:17] I would really prefer not to leave the current implementation in place for long [01:23:23] Should I ping Daniel Schwen to invite his comments on what to do with our meager resources? [01:24:18] Eloquence: Thanks for pointing out that IIP is not quite ready for production, that’s helpful to know. Do we know what it would take to get it to a better shape? [01:25:17] All right, folks, I’m heading home now. Thanks for this last push to get the zoom link out the door. Will email Pau and Gilles tonite, once the feature is on beta. See you in the morning. [01:25:19] fabriceflorin, we'd want to assess the library (code quality/security review, performance assessment, etc.) and then decide whether it's suitable for production use or whether we have to build our own. [01:26:37] if we are not going to use the zoom viewer, we should probably get https://bugzilla.wikimedia.org/show_bug.cgi?id=54035 fixed and request all thumbnail URLs at one when the user first clicks the image [01:27:12] it does not look like a horribly complicated thing [01:27:31] Eloquence: Thanks, that sounds like a good plan. If only we had two multimedia teams, we could keep one going on these issues, while the other pushes on the other fronts. Tomorrow’s another day :) [01:27:55] hungry hungry hackers [01:28:20] om nom nom hacks [01:28:27] Hehe. [01:29:09] tgr: Are you thinking that if we fixed #54035, we might be able to build a simple zoom feature based on these three sizes? [01:29:38] we could make the current one maintainable, at least [01:29:49] like, make it open in the same window [01:30:10] or open it in a new window without three layers of deferreds [01:30:33] we could fix the download button which also has some weirdness related to this [01:30:46] tgr: Is the reason we’re not opening in the same window because we’re afraid of crashing the browser with huge original image files? or is it another reason? [01:31:26] the reason is that it might take a while to learn the URL to which we should go [01:32:11] and that raises all sorts of usability issues, like the user not understanding why nothing is happening, or witching to the next image then being navigated away to the old one [01:32:13] it's on beta now, but fullsize images don't load (issue with beta config?) [01:33:01] also getting magical spinner [01:33:09] Eloquence: Yes, I found that issue earlier too when I was testing the IE fix, couldn’t tell if it was site-specific or not. [01:33:58] somehow, we are requesting the images from upload.beta instead of upload.wikimedia [01:34:17] Hm. [01:34:21] I also got an error when trying to zoom on the bridge image: http://upload.beta.wmflabs.org/wikipedia/en/thumb/0/01/The_Bridge_%28August_2013%29.jpg/3000px-The_Bridge_%28August_2013%29.jpg [01:34:37] Error generating thumbnail: The source file 'The_Bridge_(August_2013).jpg' does not exist. [01:35:18] so the logic here is, we're generating a 3000px thumb because the actual original may be too huge, or an SVG, or whatever? [01:35:51] SVG might wind up being smaller than a scalar 3000px image [01:36:05] But anyway [01:36:11] Something like that. [01:36:22] mh [01:36:25] yeah, size is capped to 3000px [01:36:33] if it is smaller, we show the original [01:36:40] ah [01:36:42] unless it is an SVG or something [01:37:13] Hmm. I’m getting infinite load on a white screen when I hit ‘back’ on some of these images: http://bits.beta.wmflabs.org/static-master/extensions/MultimediaViewer/resources/mmv/img/ajax-loader.gif [01:37:14] tgr: Do we do comparison of *file* size? [01:37:27] Or physical size? [01:37:47] Because an SVG that's 10,000 pixels but has no contents is way smaller than a 3,000 pixel thumbnail of the same. [01:38:57] well, it works now [01:39:09] maybe something was broken on beta? [01:39:29] *shrug* possible [01:39:54] marktraceur: no, just width [01:40:35] not sure how we would do a size limit, you can't request an image with a given file size [01:40:58] Guys, I hate to say this, but I think we will be getting some flack for this implementation of Zoom, if production performs the same as beta. There are a lot of rough spots, from the long image loads to the separate tab with not ‘back’ button, and no instructions to tell the user what’s going on. [01:41:16] (03PS1) 10Brian Wolff: Add transcodereset to api token list [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/133405 (https://bugzilla.wikimedia.org/65197) [01:41:39] No, but the imageinfo API response gives you file size [01:41:42] We could figure it out [01:41:49] fabriceflorin: probably [01:42:12] the question is, do we get less flak than not having a zoom at all? [01:42:24] tgr: I don't think so [01:42:56] As I said last week and in emails, I don't consider zoom to be a blocker for this deployment. It would just be Really Nice To Have® [01:43:04] What do you think? Is it good enough to ship in its current form? Is there any way to add a tooltip to explain this is a beta feature that will open up in a separate tab? [01:43:27] the speed cannot be helped as far as I can see it, these are huge images and the thumbnails need to be rendered [01:44:09] fabriceflorin: I'm playing with it on labs, and IMO I don't think it's good enough for what we're trying to do as well as how great the rest of the MMV at the moment [01:44:17] so if we use the same tab, or the advanced design, the user still has to wait [01:45:04] tgr and Keegan : Being a cautious man by nature, I would be inclined to hold off on introducing this feature as it is now. It introduces as many issues as it solves. I would also like to hear what Pau and Gilles have to say as well. [01:45:26] why not enable it on mediawiki.org tomorrow and have people give feedback there, then see what we can get pushed out next week? [01:45:30] feature flags ftw [01:46:25] Sure, always worth a go [01:46:38] (or even just using the different deployment branches) [01:46:54] I think it would be OK to put it on MediaWiki.org, but I am not sure we have the bandwidth to fix it before it goes to Commons on Tuesday. Can we pull it out before Tuesday, if need be? [01:47:12] that would be easier if it was behind a flag, I'm guessing [01:47:27] marktraceur: I don't think there is a way to get thumbnail sizes currently [01:47:37] Eloquence: can you clarify what you mean by flag? [01:47:56] a config setting in InitialiseSettings.php, wmgUseExperimentalZoomFeature or whatever :) [01:48:41] bonus points for inserting the word Scary into the config variable name [01:49:25] tgr: No, you're right, we'd have to estimate. [01:49:50] marktraceur: that really depends on the file type [01:49:56] marktraceur, tgr: what do you think about Eloquence ’s idea of deploying to MediaWiki with a flag? [01:50:12] But for thumbnails it's always jpg...right? [01:50:20] SVG is constant, BMP is linear, PNG is probably below linear because of compression etc [01:50:34] marktraceur: no, SVG for example becomes PNG [01:50:36] Can we easily pull it out before Tuesday if it’s still not good enough? [01:50:47] Oh hm. [01:51:15] marktraceur: also, empty white image is always the same size in PNG, random noise is linear with square of width [01:51:24] so not really predictable [01:52:02] adding size info to thumbnails in imageinfo would be easy, but even that does not help you figuring out the width for file size X [01:52:12] you can't even do that on the server side [01:52:23] Yeah. [01:52:41] Are we doing the feature flag thing tonight, or tomorrow? We can presumably SWAT it out. [01:52:58] wgOhMyGodWhatAreYouDoingZoomFeature = true; [01:53:05] heh [01:53:18] If we do the feature flag, can we easily pull it out before Tuesday, if it’s not ready for prime time? [01:53:24] Yup [01:53:34] fabriceflorin, we'd just not enable it anywhere else yet [01:53:35] Trivial, in fact, we can do the feature flag as late as Monday and be fine. [01:53:59] that's the point of a flag - it can then be selectively rolled out independent of which version of the code is deployed [01:54:03] (03PS1) 10Gergő Tisza: Basic funnel data logging for UploadWizard [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/133406 [01:54:12] marktraceur: can you look at ^^ ? [01:54:40] should I add a feature flag then? [01:54:47] Ok, then I think it would be fine to do a feature flag tomorrow, for the purposes of getting feedback. Keep it separate from the release, do it when you think you’re ready. [01:55:09] If you think you’re ready tonight, that’s fine by me. [01:55:18] I mean, we can do the feature flag on Monday. [01:55:22] No need to spend more time tonight. [01:55:27] At least not at the office [01:55:29] * marktraceur goes home [01:55:32] :) [01:55:33] yeah [01:55:36] that can be done anytime [01:55:41] Oh, OK, that sounds reasonable to me. [01:55:49] so the goal would be to go to mw.org tomorrow (which we'll do anyway as part of the train), get feedback there, and hold back further rollout if needed. [01:56:00] Do we need to unmerge this feature from the main release that goes out tomorrow, then? [01:56:27] it should only go into the wmf5 branch [01:56:40] which is deployed to mw.org tomorrow [01:56:41] OK, that works for me, if it works for the rest of you. [02:05:16] (03PS1) 10Gergő Tisza: Feature flag for zoom [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/133407 [02:05:29] now with 100% more scary! [02:06:25] gi11es: can you review ^^ before the branches are cut? [02:06:57] \o/ [02:42:21] tgr wins for incorporating both Scary and Hack [06:54:38] (03PS1) 10Gergő Tisza: Feature flag for Zoom Viewer [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/133420 [07:11:45] (03PS2) 10Gergő Tisza: Feature flag for Zoom Viewer [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/133420 [07:14:15] (03CR) 10Gilles: "The point is that the variable isn't defined inside the script. I can't run it if your username is hardcoded inside of it, it mean that I " [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/133353 (owner: 10MarkTraceur) [07:39:32] (03PS1) 10Gilles: Remove hardcoded username/home [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/133423 [07:40:15] (03CR) 10Gilles: [C: 032 V: 032] Remove hardcoded username/home [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/133423 (owner: 10Gilles) [07:40:25] (03CR) 10Gilles: "https://gerrit.wikimedia.org/r/#/c/133423/" [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/133353 (owner: 10MarkTraceur) [07:43:36] (03PS1) 10Gilles: Deploy needs to run from the checkout folder [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/133424 [07:43:56] (03CR) 10Gilles: [C: 032 V: 032] Deploy needs to run from the checkout folder [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/133424 (owner: 10Gilles) [07:44:14] (03CR) 10Gilles: "https://gerrit.wikimedia.org/r/#/c/133424/" [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/133353 (owner: 10MarkTraceur) [07:45:46] (03CR) 10Gilles: "Also I've noticed that your crons ran just before midnight UTC. It'd be better if they ran after midnight, because the current unfinished " [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/133353 (owner: 10MarkTraceur) [07:55:51] (03CR) 10Gilles: [C: 04-1] "I'm not a fan of adding a new user option for this. Both options are sub-par user experiences. We should pick one. We can still make it co" (031 comment) [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/133420 (owner: 10Gergő Tisza) [07:58:00] gi11es: on retrospect I would actually remove both [07:58:07] see the mail I just sent [07:58:12] no tests etc [08:20:05] gi11es when https://gerrit.wikimedia.org/r/#/c/133218/ would be deployed? [09:14:51] (03PS1) 10Rillke: UploadWizard: Check for duplicate titles [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/133434 (https://bugzilla.wikimedia.org/64883) [09:18:58] (03PS2) 10Rillke: UploadWizard: Check for duplicate titles [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/133434 (https://bugzilla.wikimedia.org/64883) [09:54:40] (03CR) 10Siebrand: [C: 04-1] "i18n/L10n reviewed." (032 comments) [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/133434 (https://bugzilla.wikimedia.org/64883) (owner: 10Rillke) [10:51:00] (03PS3) 10Rillke: UploadWizard: Check for duplicate titles [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/133434 (https://bugzilla.wikimedia.org/64883) [10:59:10] (03PS4) 10Rillke: UploadWizard: Check for duplicate titles [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/133434 (https://bugzilla.wikimedia.org/64883) [11:01:52] (03PS5) 10Rillke: UploadWizard: Check for duplicate titles [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/133434 (https://bugzilla.wikimedia.org/64883) [11:08:31] (03CR) 10Gilles: [C: 04-1] "The "version" field is unnecessary. Schemas are already versioned by default (current version is 8527476) and the data for each version go" [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/133406 (owner: 10Gergő Tisza) [11:12:01] (03CR) 10Gilles: [C: 04-1] Feature flag for zoom (031 comment) [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/133407 (owner: 10Gergő Tisza) [11:13:30] (03PS6) 10Rillke: UploadWizard: Check for duplicate titles [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/133434 (https://bugzilla.wikimedia.org/64883) [11:15:09] (03CR) 10Rillke: UploadWizard: Check for duplicate titles (032 comments) [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/133434 (https://bugzilla.wikimedia.org/64883) (owner: 10Rillke) [11:18:18] matanya: today, I think? but I don't know what deploy group hebrew wikipedia is part of [11:18:30] depending on which one it's in, it might get it only next week unless we backport the change [11:18:46] group2 gi11es [11:21:10] yes, then it needs a backport [11:21:32] I'll see what I can do, I've never done one myself, but I can try my best to prepare it for mark or gergo [11:21:52] it'll only get through if they get to the office early enough, though [11:23:48] so today or monday if not backported ? [11:26:19] latest next week [11:28:37] it can happen during SWAT windows as well if I miss today's deploy [11:28:49] which are scheduled every morning pacific time [11:29:14] I'm sure marktraceur and tgr will find a way to get it through today [11:41:51] (03PS1) 10Gilles: Fix IE9 support [extensions/MultimediaViewer] (wmf/1.24wmf4) - 10https://gerrit.wikimedia.org/r/133446 (https://bugzilla.wikimedia.org/65225) [11:44:15] thanks [12:18:25] (03CR) 10Fomafix: "I wonder. When and how do you want to apply the coding conventions? Do you want to combine changes for coding conventions with functional " [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/132957 (owner: 10Gerrit Patch Uploader) [12:40:40] (03PS1) 10Krinkle: Restrict Verified+1/2 and Submit to JenkinsBot and l10n-bot [extensions/MultimediaViewer] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/133451 [12:40:42] (03CR) 10jenkins-bot: [V: 04-1] Restrict Verified+1/2 and Submit to JenkinsBot and l10n-bot [extensions/MultimediaViewer] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/133451 (owner: 10Krinkle) [12:40:50] (03CR) 10Krinkle: [C: 032] Restrict Verified+1/2 and Submit to JenkinsBot and l10n-bot [extensions/MultimediaViewer] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/133451 (owner: 10Krinkle) [12:40:52] (03CR) 10jenkins-bot: [V: 04-1] Restrict Verified+1/2 and Submit to JenkinsBot and l10n-bot [extensions/MultimediaViewer] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/133451 (owner: 10Krinkle) [12:41:11] (03CR) 10Krinkle: [C: 032 V: 032] Restrict Verified+1/2 and Submit to JenkinsBot and l10n-bot [extensions/MultimediaViewer] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/133451 (owner: 10Krinkle) [12:59:25] (03CR) 10Gilles: "What's going on? Is there an emergency? I don't recall anyone on our team abusing those abilities on this repo recently." [extensions/MultimediaViewer] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/133451 (owner: 10Krinkle) [13:35:54] (03PS1) 10Gilles: Add 1 pixel of tolerance to the basic test [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/133459 [14:11:36] (03CR) 10MarkTraceur: "Either way." [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/132957 (owner: 10Gerrit Patch Uploader) [14:42:38] (03CR) 10Fomafix: "Have a lot of fun with identifying a functional change when it is combined with coding convention changes." [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/132957 (owner: 10Gerrit Patch Uploader) [15:01:50] (03CR) 10Anomie: [C: 032] "Looks good for SWAT" [extensions/MultimediaViewer] (wmf/1.24wmf4) - 10https://gerrit.wikimedia.org/r/133446 (https://bugzilla.wikimedia.org/65225) (owner: 10Gilles) [15:02:41] (03Merged) 10jenkins-bot: Fix IE9 support [extensions/MultimediaViewer] (wmf/1.24wmf4) - 10https://gerrit.wikimedia.org/r/133446 (https://bugzilla.wikimedia.org/65225) (owner: 10Gilles) [15:07:42] (03CR) 10MarkTraceur: "..." [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/132957 (owner: 10Gerrit Patch Uploader) [15:26:04] (03CR) 10Anomie: Add transcodereset to api token list (031 comment) [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/133405 (https://bugzilla.wikimedia.org/65197) (owner: 10Brian Wolff) [15:56:46] (03CR) 10Siebrand: UploadWizard: Check for duplicate titles (031 comment) [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/133434 (https://bugzilla.wikimedia.org/64883) (owner: 10Rillke) [15:56:58] (03CR) 10Siebrand: [C: 031] "i18n/L10n reviewed." [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/133434 (https://bugzilla.wikimedia.org/64883) (owner: 10Rillke) [15:57:14] (03PS1) 10Pginer: More prominent metadata panel invite [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/133489 [15:57:56] (03CR) 10jenkins-bot: [V: 04-1] More prominent metadata panel invite [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/133489 (owner: 10Pginer) [16:02:08] (03PS2) 10Pginer: More prominent metadata panel invite [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/133489 [16:02:52] (03CR) 10jenkins-bot: [V: 04-1] More prominent metadata panel invite [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/133489 (owner: 10Pginer) [16:46:32] marktraceur: looking for IE9 user ? [16:47:09] matanya: fabrice has tested it now [16:47:16] Should be working on commons and mediawiki [16:47:36] great, so you backported the fix ? [16:47:36] Yup [16:47:45] SWATted out about an hour ago [16:48:06] yay, thanks! [17:06:11] (03CR) 10Gilles: "The QUnit errors seem unrelated to your changes. The first place I'd look is breaking changes in OOUI, since the affected tests are the on" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/133489 (owner: 10Pginer) [17:06:20] i'll repeat, I think I was still offline (irssi is weird) [17:06:21] 10:03 <+tgr> marktraceur: the GWToolset core patch was merged two days ago, we need to backport it if we want to merge the config changes [17:06:24] 10:04 <+tgr> but we basically agreed that the throttling is not good enough to reenable large uploads, so there is no urgency IMO [17:06:34] or am I misunderstanding something? [17:06:35] You were offline, yeah [17:06:39] Sec [17:06:53] tgr: That sounds right [17:07:11] ok, I'll update the deployments page [17:11:47] marktraceur: thanks for taking care of the SWAT [17:13:53] Yup! [17:14:45] unrelatedly, our qunit tests have started failing, presumably due to a core update [17:14:57] just in time for the deploy cutoff... [17:15:02] on share & embed [17:15:13] pau's changeset surfaced it: https://gerrit.wikimedia.org/r/#/c/133489/ [17:17:24] the feature itself doesn't look broken [17:17:32] (03CR) 10Gergő Tisza: "A commit to disable manual verification, which had to be verified manually to merge! What could go wrong?" [extensions/MultimediaViewer] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/133451 (owner: 10Krinkle) [17:18:09] right [17:18:19] so can someone with direct push access undo that? [17:18:59] ffs. [17:19:14] We need to find the issue first [17:19:28] (03CR) 10MarkTraceur: "recheck" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/133489 (owner: 10Pginer) [17:20:50] awwjenkins [17:20:51] Tests fail locally for me after update, finding error [17:21:18] Not enough assertions... [17:21:40] the issue is that jenkins creates fake errors every once in a while and making it impossible to override them is stupid [17:21:50] assuming we are talking about the same issue... [17:26:37] Dunno, maybe [17:28:16] There are a *lot* of failures [17:29:00] i wasn't talking about any current failures, disabling manual V+2 is just a bad idea in general [17:29:35] and I cannot even revert it since config changes need manual V+2 due to a Jenkins bug... fun [17:29:58] Core tests failing too. [17:36:15] the first one only has 3 assert.ok ( true... [17:36:25] i.e. the error seems genuine [17:36:30] automerge fuckup, perhaps [17:36:37] Yeah probably [17:36:39] Not sure how. [17:37:39] no change for a month [17:37:52] probably some of those should be invoked multiple times [17:38:41] I guess [17:38:43] could some behavior change in OOjs UI about the number of events emitted [17:39:56] (03CR) 10Krinkle: "1) this is only for master" [extensions/MultimediaViewer] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/133451 (owner: 10Krinkle) [17:40:16] (03CR) 10Krinkle: "https://gerrit.wikimedia.org/r/#/q/status:merged+ref:refs/meta/config+message:JenkinsBot+owner:%22Krinkle+%253Ckrinklemail%2540gmail.com%2" [extensions/MultimediaViewer] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/133451 (owner: 10Krinkle) [17:41:29] https://gerrit.wikimedia.org/r/#/c/132316/ -> this was changed yesterday but seems harmless at a glance [17:43:01] onDocumentMouseDown maybe? [17:43:21] yeah, I am looking at that [17:43:42] I'll revert before and after that commit to check if it's the cause [17:45:58] it's not that OOUI update, it's something more recent [17:46:17] which makes sense, since I pushed something a couple of hours before pau and the tests worked fine then [17:46:43] I'll keep playing with reverting back and forth until I find the culprit [17:47:11] git bisect? [17:49:52] didn't know that existed :) I don't need a tool for such a small amount of commits, but good to know next time this happens on a large amount [17:51:30] it's the jQuery upgraed [17:52:01] upgrayedd for a double dose of pimping [17:52:14] maybe they finally changed how the deferreds work? [17:52:22] gi11es: Wait, the 1.9 thing happened? [17:52:30] 1.11? [17:52:43] Well, 1.11 wasn't the issue [17:52:58] marktraceur: Yes, 1.8 -> 1.9 (1.11) merged a few minutes before the cut. [17:52:59] pushed with jQuery migrate [17:53:04] A few MINUTES. [17:53:12] which evidently isn't 100% compatible... [17:53:19] *sigh* [17:53:24] marktraceur: I know, right? :-( [17:53:42] marktraceur: I asked Krinkle to do it a few days ago (he's said it was going out in wmf5, but that's no excuse). [17:53:46] FFS. [17:54:25] a fun day ahead for you guys [17:54:29] Always [17:54:34] * James_F hugs marktraceur. [17:56:25] Gee maybe things that could break tests for all javascript shouldn't get merged right before the cut and give everyone heart attacks [17:56:41] well, let's hope it *only* breaks tests [17:57:19] I don't see any breakage in the interface [17:57:45] I'll run the E2E [17:58:23] The best part is, the core tests fail too [17:59:18] Or...only for me maybe [17:59:29] E2E passes [17:59:45] I'm seein failures in core tests after ours as well, locally [18:00:10] Did Jenkins too? [18:00:47] for me only two share panel tests fail [18:01:01] Hm [18:01:31] Oh [18:01:38] gi11es: debug=true causes the core failures [18:01:44] hah [18:03:07] on chrome I see that same as gergo with debug=1 [18:03:12] it's on firefox that I saw extra failures [18:03:35] Ah. [18:09:46] apparently a focus() call on an element does not trigger the OOJS UI onDOMEvent focus handler anymore [18:10:14] or maybe it does but too late for the test to see it [18:10:41] wait, the jQuery 1.11 didn't make it to the deploy today, right? [18:10:48] because Reedy already had made the branch [18:12:09] not sure, Jenkins tests against current master so we would see the errors either way [18:13:31] it didn't make it, no. so this is just on master [18:18:34] (03CR) 10Brian Wolff: Add transcodereset to api token list (031 comment) [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/133405 (https://bugzilla.wikimedia.org/65197) (owner: 10Brian Wolff) [18:34:49] (03CR) 10Anomie: Add transcodereset to api token list (031 comment) [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/133405 (https://bugzilla.wikimedia.org/65197) (owner: 10Brian Wolff) [18:38:08] right, so this is http://jquery.com/upgrade-guide/1.9/#order-of-triggered-quot-focus-quot-events [18:38:40] jQuery invokes the native focus() method now instead of doing the handler triggering manually [18:38:59] and the native focus call does not trigger the handler [18:42:44] which is funny because the upgrade documentation says the exact opposite [19:12:03] marktraceur: http://bugs.jquery.com/ticket/13363 [19:12:15] I think this accounts for the FF/Chrome difference [19:12:31] Hm. [19:12:32] 'kay [19:13:21] I'll just change all the focus() calls in the tests to triggerHandler('focus') as suggested in that ticket [19:13:46] it does feel like a copout though... [19:27:23] (03PS1) 10Gergő Tisza: Fix failing focus tests [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/133530 [19:28:07] Hm, we should probably clean up all of the orphaned BetaFeature user_property entries [19:28:14] James_F: ^^ [19:29:20] marktraceur: There's a script for that. [19:29:25] Ooh. [19:30:21] marktraceur: maintenance/dosomethingfunky.php or similar. [19:30:29] marktraceur: Sorry, not helpful. I blame the heat. [19:31:00] James_F: You run that script and a disco ball descends, the lights go out, and everyone is magically wearing bell-bottoms [19:31:18] Sounds about right. [19:37:15] marktraceur tgr : Hi guys, I am writing an FAQ to invite community members to tag unrelated maintenance images with a ‘.metadata’ class, to prevent them from appearing in Media Viewer. What is the exact script they need to add to make this happen? Is there a link to a page that explains more about this practice? [19:37:23] Here’s what I would like the FAQ to say (with the proper script, of course): [19:37:24] "Sometimes, Media Viewer displays metadata images (e.g. icons, flags) that are not related to the page's topic and confusing to users. To exclude these images in Media Viewer, we recommend adding this CSS class around the image tag: [19:37:24] [ [ File:Foo.png ] ] . . [19:37:54] you don't need the dot, otherwise looks right [19:37:58] Urhm...probably

but otherwise that seems fine, yeah [19:38:12] [[File:Foo.png]] is fine but |frameless will cock up the span [19:38:54] a div causes a linebreak, which might be unwanted [19:39:16] I mean if it's a block element [19:39:21] a span is sometimes technically invalied HTML but will always display correctly as far as I can see [19:39:28] Oh, 'kay. [19:39:42] * marktraceur +1s it as is then [19:39:49] Still not seeing our config change go out [19:41:10] fabriceflorin: you can write something like [[File:Foo.png]] and then you don't need the spaces [19:41:15]