[00:12:22] <marktraceur>	 Our metrics should be working now EOM
[00:33:48] <marktraceur>	 OK, actually walk first, but LD is over and we're set up
[00:46:45] <tgr>	 played around with testing of incremental loading a bit
[00:46:56] <tgr>	 http://www.charlesproxy.com is nice but non-free
[00:49:35] <tgr>	 incremental loading works fine for the initial image
[00:49:56] <tgr>	 but paging is completely weird
[00:55:20] <tgr>	 i take it back, now everything works fine
[00:55:46] <tgr>	 even progressive loading for jpegs
[00:56:14] <marktraceur>	 OK then
[00:56:22] <marktraceur>	 tgr: I think I will say that's good enough for me
[00:56:27] <tgr>	 if you navigate away before the image has fully loaded, that causes problems
[00:56:49] <tgr>	 not sure if that is a new bug or just not noticable without slowing things down
[00:57:03] <tgr>	 but IMO the patch can go out
[00:57:14] <marktraceur>	 'kay, will do that then
[00:57:33] <grrrit-wm>	 (03CR) 10MarkTraceur: [C: 032] Load images normally [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/100693 (owner: 10MarkTraceur)
[00:57:42] <marktraceur>	 I definitely saw it working, just not in a way I expected
[00:57:48] <marktraceur>	 Probably due to it being too fast locally
[00:58:01] <grrrit-wm>	 (03Merged) 10jenkins-bot: Load images normally [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/100693 (owner: 10MarkTraceur)
[01:06:26] <marktraceur>	 Oh, wow, the metadata fetch time
[01:16:01] <marktraceur>	 OK, fabriceflorin et al., should I make a new limn instance for us on labs, or should we use the e2 instance or something equally silly?
[01:18:04] <fabriceflorin>	 marktraceur: This would be a good question for DarTar. I'm not opposed to piggybacking on top of the e2 instance, but he might. If you want more control, it may be easier to do it on labs, but it's a complex system with weird permissions, so I would definitely ping him.
[01:18:15] <marktraceur>	 Right
[01:18:27] <marktraceur>	 Well, I have the capacity to deal with labs
[01:18:36] <fabriceflorin>	 how did the lightning deploy go? anything new to test?
[01:18:38] <marktraceur>	 So it's mostly a question of setting it up
[01:18:50] <marktraceur>	 fabriceflorin: Honestly I ran a few MMV instances and it didn't seem to crash, so I'm happy
[01:18:58] <marktraceur>	 Nothing user-facing went out, just a fix for metrics
[01:19:30] <fabriceflorin>	 Oh, OK. Will tomorrow's deployment still have the old UI then?
[01:20:25] <marktraceur>	 No, it will have major updates on mediawiki.org but not on any other non-test wiki
[01:20:43] <marktraceur>	 I think including everything in our goals *but* fullscreen
[01:20:52] <marktraceur>	 http://etherpad.wikimedia.org/p/multimedia-weekly-meeting-2014-01-06 has the whole gory details
[01:21:01] <marktraceur>	 About everything
[01:21:13] <marktraceur>	 I abused our weekly meeting minutes as my notebook for the week
[01:21:31] <fabriceflorin>	 Oh cool. That's really good news. Would these then be pushed to Commons + sister sites next Tue. and all wikis the following Thursday?
[01:21:43] <marktraceur>	 Yes.
[01:22:10] <fabriceflorin>	 Hehe. I think it's great you're using the Etherpad productively.
[01:43:27] <grrrit-wm>	 (03CR) 10Gergő Tisza: [C: 032] Add support for more Flickr URLs [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/105393 (owner: 10M4tx)
[01:43:28] <bawolff>	 fabriceflorin: btw, did you see Dschwen's work on category intersection? Its super awesome
[01:43:35] <grrrit-wm>	 (03Merged) 10jenkins-bot: Add support for more Flickr URLs [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/105393 (owner: 10M4tx)
[01:45:01] <fabriceflorin>	 bawolff: Thanks for the tip. I saw his announcement, but haven't tested the tool yet. What's the best way to check it out? 
[01:45:57] <bawolff>	 Just go to https://commons.wikimedia.org/w/index.php?title=Help:FastCCI&withJS=MediaWiki:ActivateGadget.js&gadgetname=fastcci , click yes to the prompt, go to some random category
[01:47:05] <bawolff>	 You can get the main idea from the screenshots
[01:49:52] <marktraceur>	 Oh man that's cool
[01:49:58] <fabriceflorin>	 That's lovely, thanks so much for the tip! This is a cool way to surface the best content. I'll thank him for this nice contribution, and we may be able to incorporate some of this in our own tools --- as well as give his UI a bit of design love.
[01:51:46] <bawolff>	 I think at this stage he's still somewhat in early beta as to what to actually do with the tool
[01:53:01] <bawolff>	 I'm honestly quite surprised he made this all work. I always assumed the category tree was just too messy to do this sort of thing to infinite depth more or less "instantly"
[01:58:49] <fabriceflorin>	 Yeah, Daniel is really ingenious. I'd like to find a way to work more closely with him on some of our upcoming projects. For now, he's doing useful experimental work that can inform our next steps.
[01:59:32] <fabriceflorin>	 I thanked him for his work on Village Pump. He deserves some kudos for pushing the envelope on so many fronts.
[02:30:21] <grrrit-wm>	 (03PS1) 10Gergő Tisza: Fix metadata loading [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106480 
[10:16:09] <grrrit-wm>	 (03PS4) 10Apsdehal: Reduce font-size for description in lightbox [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/105154 
[12:03:27] <grrrit-wm>	 (03PS9) 10Apsdehal: Titles attribute added to some buttons in interface [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/105459 
[12:39:36] <grrrit-wm>	 (03CR) 10Gilles: "Pau approved this version of the change by email" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106224 (owner: 10Gilles)
[12:55:42] <grrrit-wm>	 (03CR) 10Gilles: "I think this introduces a semantic discrepancy that I find problematic. Either the lightbox affects the location, in which case history s" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/97919 (owner: 10Gergő Tisza)
[13:13:38] <grrrit-wm>	 (03CR) 10Theopolisme: [C: 031] Reduce font-size for description in lightbox [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/105154 (owner: 10Apsdehal)
[14:14:03] <grrrit-wm>	 (03CR) 10Gilles: [C: 04-1] "I'm not super familiar with existing best practices when it comes to writing new backend endpoints, is anyone on the review list more fami" (032 comments) [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/65109 (owner: 10Nischayn22)
[14:15:58] <grrrit-wm>	 (03CR) 10Gilles: "I'll take a look at this once my concerns about the backend have been clarified." [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/42770 (owner: 10Nischayn22)
[14:29:23] <grrrit-wm>	 (03CR) 10Gilles: [C: 04-1] "What Gergő said, you don't want promises/deferreds that are never ended." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106004 (owner: 10MarkTraceur)
[15:27:19] <grrrit-wm>	 (03CR) 10Anomie: "In MediaWiki, there are two ways to run an extension's unit tests. Method 1 is by pointing phpunit at the extension's directory where it w" [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/65109 (owner: 10Nischayn22)
[16:11:46] <marktraceur>	 gi11es: Yay mumble
[16:18:03] <bd808>	 [9:17 AM] Welcome to Mumble.
[16:18:03] <bd808>	 [9:17 AM] Connecting to server api.btcfile.com.
[16:18:03] <bd808>	 [9:17 AM] Server connection failed: The remote host closed the connection.
[16:18:33] <bd808>	 gi11es: Your mumble server doesn't like me. :/
[16:18:51] <gi11es>	 what client are you using? stock one?
[16:19:17] <bd808>	 Mumble v1.2.4 on OSX
[16:19:46] <gi11es>	 I have 1.2.3, seems to be the only differenge
[16:19:50] <gi11es>	 difference
[16:20:09] <gi11es>	 what happens when you telnet api.btcfile.com 64738 ?
[16:20:16] <bd808>	 I connected the other day, but then I changed to a "real" certificate from comodo and haven't been able to connect since
[16:20:37] <gi11es>	 what real certificate? there is none for my site
[16:21:18] <bd808>	 I switched my client cert from a self-signed to a comodo client auth cert
[16:21:44] <bd808>	 http://mumble.sourceforge.net/Obtaining_a_Comodo_Certificate
[16:22:24] <gi11es>	 I'll have a look at the murmur log
[16:23:12] <bd808>	 I can switch back to a self-signed cert too. That might fix things
[16:23:18] <gi11es>	 <W>2014-01-09 16:23:48.143 1 => <21:(-1)> New connection: 67.60.0.124:60299
[16:23:19] <gi11es>	 <W>2014-01-09 16:23:52.299 1 => <21:(-1)> Connection closed: Error during SSL handshake: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number [13]
[16:23:22] <gi11es>	 it probably will
[16:25:13] <gi11es>	 seems to be a TLS version issue, but I'm not sure that's something murmur would allow me to configure
[16:28:05] <gi11es>	 seems like it's fixed on the latest version of murmur
[16:28:09] <gi11es>	 https://github.com/SFTtech/sftmumblebot/issues/1
[16:28:36] <gi11es>	 ah, no, actually, that but is about someone forcing their cert to use TLSv1 on a bot
[16:28:57] <gi11es>	 can you do that for your comodo cert? seems like it's using TLS 1.1
[16:30:05] <gi11es>	 could still be that my server is outdated, according to stuff I'm reading
[16:30:30] <gi11es>	 hmmm nope, well...
[16:32:29] <gi11es>	 going back to self-signed will definitely solve your issue for now, I think. and I have no idea how I could somehow make my server accept the TLSv1.1 cert
[16:36:45] <bd808>	 I seem to be connected with the self-signed cert. {{worksforme}}
[16:38:43] <gi11es>	 have you disconnected already? I don't see you in the userlist
[16:40:53] <bd808>	 gi11es: Yeah I jumped off
[16:41:16] * bd808  is back on mumble

[16:54:38] <marktraceur>	 fabriceflorin: Still remote?
[16:55:01] <fabriceflorin>	 Nope, on the bus. See you around 9:45am.
[16:55:21] <marktraceur>	 Woo
[16:55:50] <fabriceflorin>	 marktraceur: Yeah, feels great to be alive again -- and no longer contagious :)
[16:56:02] <fabriceflorin>	 When will the new UI changes go live on MediaWiki.org? Early afternoon?
[16:56:19] <marktraceur>	 Probably during metrics
[16:56:37] <marktraceur>	 Grumble grumble disruptions
[16:56:58] <marktraceur>	 Oh wait
[16:57:02] <marktraceur>	 You're presenting the vision?
[17:00:37] <fabriceflorin_>	 Did I miss anything during the bridge crossing?
[17:03:30] <marktraceur>	 fabriceflorin: I said "Wait, you're presenting the vision?"
[17:03:35] <marktraceur>	 (at metrics)
[17:04:00] <fabriceflorin>	 marktraceur: Yes, I signed up for a quick vision presentation, if time allows.
[17:04:21] <marktraceur>	 Cool.
[17:04:55] <fabriceflorin>	 Did I miss anything else during either the bridge or tunnel crossings? (hehe)
[17:04:56] <grrrit-wm>	 (03PS1) 10Gilles: Only scroll to the top when opening the lightbox [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106533 
[17:05:24] <grrrit-wm>	 (03CR) 10jenkins-bot: [V: 04-1] Only scroll to the top when opening the lightbox [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106533 (owner: 10Gilles)
[17:05:35] <marktraceur>	 fabriceflorin: I don't think so; I said that the UI changes would go out during Metrics
[17:06:33] <fabriceflorin>	 Excellent. Does this include improvements to the spinner and metadata panel obstruction?
[17:06:46] <marktraceur>	 Uh. Yes!
[17:06:55] <marktraceur>	 But not a fix to Pau's comment, I think
[17:07:08] <marktraceur>	 As gi11es is working on it now, I don't think I want to push too hard
[17:07:09] <fabriceflorin>	 Splendid. Just wanted to dot the i's. Thanks for your fabulous work on all this in recent days!
[17:07:48] <marktraceur>	 Ah, everyone pitched in, I spent a lot of time mucking around with analytics toys :P
[17:08:04] <gi11es>	 gah, forgot to run jshint again
[17:08:10] <marktraceur>	 :)
[17:08:11] <gi11es>	 would be good to get that last fix in
[17:08:27] <marktraceur>	 gi11es: There's a way to enable it to run automatically on save in vim (and probably other editors)
[17:08:27] <gi11es>	 Identifier 'scroll_top_before_opening_lightbox' is not in camel case :(
[17:08:33] <gi11es>	 you guys enforce camel case?
[17:08:39] <marktraceur>	 Lol.
[17:08:41] <fabriceflorin>	 Even better. I feel that our team is starting to gel and we're now moving at a faster clip. With Gilles onboard, it can only get better ...
[17:08:57] <marktraceur>	 gi11es: I prefer it, this isn't Python...I think it's in the CC document
[17:09:18] <marktraceur>	 gi11es: https://www.mediawiki.org/wiki/CC/JS#Naming
[17:11:48] <grrrit-wm>	 (03PS2) 10Gilles: Only scroll to the top when opening the lightbox [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106533 
[17:12:25] <gi11es>	 consistency is good :) at least jshint will catch any relapse I have in the future
[17:14:55] <grrrit-wm>	 (03PS1) 10Reedy: Hack to fix bug 59780 [extensions/TimedMediaHandler] (wmf/1.23wmf10) - 10https://gerrit.wikimedia.org/r/106535 
[17:15:14] <grrrit-wm>	 (03CR) 10Reedy: [C: 032] Hack to fix bug 59780 [extensions/TimedMediaHandler] (wmf/1.23wmf10) - 10https://gerrit.wikimedia.org/r/106535 (owner: 10Reedy)
[17:15:24] <grrrit-wm>	 (03Merged) 10jenkins-bot: Hack to fix bug 59780 [extensions/TimedMediaHandler] (wmf/1.23wmf10) - 10https://gerrit.wikimedia.org/r/106535 (owner: 10Reedy)
[17:15:32] <grrrit-wm>	 (03PS2) 10Reedy: Hack to fix bug 59780 [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/106134 
[17:15:39] <grrrit-wm>	 (03CR) 10Reedy: [C: 032] Hack to fix bug 59780 [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/106134 (owner: 10Reedy)
[17:15:41] <grrrit-wm>	 (03Merged) 10jenkins-bot: Hack to fix bug 59780 [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/106134 (owner: 10Reedy)
[17:17:21] <gi11es>	 what's our responsibility regarding TimeMediaHandler at the moment?
[17:17:29] <gi11es>	 responsible for it but not our focus yet?
[17:20:47] <marktraceur>	 gi11es: Something like "We are aware of it and will help if we need to"
[17:26:09] <marktraceur>	 Oh, we aren't Mumbling today? :(
[17:36:04] <grrrit-wm>	 (03CR) 10Aarcos: [C: 04-1] Only scroll to the top when opening the lightbox (032 comments) [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106533 (owner: 10Gilles)
[17:39:34] <mayankmadan>	 aarcos, anything wrong with https://gerrit.wikimedia.org/r/#/c/103596/ now?
[17:39:43] <grrrit-wm>	 (03CR) 10Gilles: Only scroll to the top when opening the lightbox (031 comment) [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106533 (owner: 10Gilles)
[17:41:51] <marktraceur>	 aarcos: It may be that fabriceflorin, tgr and I team up on Mumble, so we may go forward with that after all - does that sound OK to you?
[17:42:20] <marktraceur>	 (cc gi11es)
[17:42:51] <gi11es>	 I'm happy with anything, I think aarcos is the only one who hasn't confirmed having mumble ready to go
[17:42:58] <marktraceur>	 Right
[17:43:29] <marktraceur>	 Well, and fabriceflorin, but we have a solution for that
[17:45:18] <marktraceur>	 I dunno if we want two computers connected from the office or just one
[17:45:48] <grrrit-wm>	 (03CR) 1001tonythomas: [C: 031] Reduce font-size for description in lightbox [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/105154 (owner: 10Apsdehal)
[17:46:52] <aarcos>	 I haven't installed mumble guys, sorry.
[17:47:31] <marktraceur>	 aarcos: It's just a DMG download, maybe you can get it before the standup?
[17:47:53] <aarcos>	 Let me try...
[17:50:55] <gi11es>	 aarcos: unsurprisingly toying with scroll in qunit context actually has no effect, even the test I wrote turns out to be a bit useless
[17:50:55] <aarcos>	 mayankmadan: Hi there !, sorry I haven't been available, I am in Zurich now and have things to do in the evening. Regarding the changes, I will make them myself and then send them to you for review. It seems too much back and forth to me.
[17:51:08] <gi11es>	 basically trying to update the document scroll during the test does nothing
[17:51:34] <gi11es>	 I will probably have to do some injection or mocking to make it really work, gotta figure that out first
[17:52:02] <marktraceur>	 gi11es: I managed to test scrolling by adding some amount of height to document.body, IIRC
[17:52:16] <gi11es>	 in which test?
[17:52:17] <marktraceur>	 Before I came to my senses about how to do it
[17:52:23] <marktraceur>	 Uhhhh, sec
[17:52:40] <gi11es>	 would be more robust to be able to do some sort of man-in-the-middle in jQuery
[17:52:40] <marktraceur>	 gi11es: https://gerrit.wikimedia.org/r/#/c/105993/1/tests/qunit/ext.multimediaViewer.test.js
[17:52:47] <marktraceur>	 The second patchset is better
[17:52:48] <aarcos>	 I was thinking just calling attach() twice !
[17:52:57] <marktraceur>	 (yeah, mitm is what I wound up with)
[17:53:17] <gi11es>	 aarcos: that part's fine, it's just that to truly test that things work, you need to scroll the details open during the qunit test
[17:53:23] <gi11es>	 and then check that it's not moved to 0 again
[17:53:38] <gi11es>	 but right now attempting to scroll in the qunit test doesn't scroll
[17:54:52] <gi11es>	 not a big surprise since in practice the lightbox is hidden when you run qunit
[17:56:25] <gi11es>	 I'll try the same approach as marktraceur with $.fn.scrollTop
[17:57:01] <marktraceur>	 aarcos: Any luck with Mumble?
[17:57:59] <tgr>	 for me it just dies a few seconds after connecting
[17:58:21] <gi11es>	 you look connect right now
[17:58:23] <gi11es>	 connected
[17:58:34] <marktraceur>	 Yeah, but the window isn't responding
[17:58:41] <aarcos>	 How about creating a function 'scrollToTopAndSaveCurrentPosition()' and its complement, then you can mock them and make sure they are called only once when you have >=2 attach() calls.
[17:59:36] <aarcos>	 marktraceur: Busy here chatting, sorry, no chance, I will give a try tomorrow though. Seeya in a bit...
[17:59:40] <marktraceur>	 'kay
[17:59:45] <gi11es>	 I prefer to monkey-patch jQuery if possible, it'll give us information closer to the reality of what happens
[18:00:12] <gi11es>	 scrollToTopAndSaveCurrentPosition since it's in our code, is subject to change that might not break the test but could break it logically speaking
[18:00:42] <marktraceur>	 Hangouts, all
[18:00:56] <aarcos>	 calling...
[18:00:58] <fabriceflorin>	 We're meeting via Hangouts today, Mumble tomorrow.
[18:12:42] <grrrit-wm>	 (03CR) 10Aarcos: [C: 031] "As agreed on the standup since this is a critical bug and the fix looks good I am approving. Someone else should +2 and hope we can get th" (031 comment) [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106533 (owner: 10Gilles)
[18:15:12] <grrrit-wm>	 (03CR) 10Gergő Tisza: "I agree it is a problem, but I still see it as the lesser one compared to spamming the history." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/97919 (owner: 10Gergő Tisza)
[18:15:52] <grrrit-wm>	 (03CR) 10MarkTraceur: "We'll have to re-fetch the entire imageinfo every time we resize with this method - are we OK with that idea?" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106480 (owner: 10Gergő Tisza)
[18:16:14] <marktraceur>	 tgr: That's a lot of API bandwidth :?
[18:16:16] <marktraceur>	 :/ even
[18:17:49] <tgr>	 hm
[18:17:52] <marktraceur>	 I'm trying to figure out how to do this
[18:17:58] <tgr>	 haven't really thought that through
[18:18:04] <marktraceur>	 I think the answer is roughly to cache individual values, but argh.
[18:18:28] <marktraceur>	 (because then if there are non-cacheable values like thumburl that we need to pay attention to, we can make the request anyway)
[18:18:41] <marktraceur>	 I say "like" thumburl but I think that's the only one we can't cache.
[18:19:24] <marktraceur>	 So maybe we should just check for the presence of a 'url' prop, make the request if it's there, else use the cache (again if present)
[18:19:35] <marktraceur>	 Now I wonder if this is doable in 40 minutes.
[18:19:46] <marktraceur>	 Or if we should just backport it
[18:20:46] <tgr>	 could segment the cache by image size
[18:21:24] <tgr>	 for handheld devices that might be useful, as they can switch a lot between two sizez, anywhere else it's probably a waste of effort
[18:22:45] <marktraceur>	 Well, since we're not actively targeting mobile right now that might be OK
[18:23:21] <grrrit-wm>	 (03CR) 10MarkTraceur: [C: 032] "Per aarcos" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106533 (owner: 10Gilles)
[18:23:40] <marktraceur>	 aarcos: Do you still not have +2 on MMV?
[18:23:52] <marktraceur>	 Because https://www.mediawiki.org/wiki/Gerrit/Project_ownership#aarcos_.2B2_for_MultimediaViewer says you do
[18:23:54] <grrrit-wm>	 (03Merged) 10jenkins-bot: Only scroll to the top when opening the lightbox [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106533 (owner: 10Gilles)
[18:24:02] <tgr>	 then again, fullscreen is also a resize
[18:24:15] <marktraceur>	 tgr: True, but still disabled
[18:26:00] <marktraceur>	 There should probably be a separate cache for image size URLs
[18:27:23] <marktraceur>	 tgr: Do you think we can do that before 11, or should we merge the nastypatch and LD something more helpful?
[18:27:58] <marktraceur>	 A cache for data-about-the-image and then a separate cache for URLs
[18:28:40] <marktraceur>	 Specifically thumburls
[18:29:17] <tgr>	 i would rather not try in half an hour, doesn't look trivial and don't want to break it even more
[18:31:27] <marktraceur>	 'kay
[18:31:29] <marktraceur>	 Fun times
[18:32:31] <grrrit-wm>	 (03CR) 10MarkTraceur: [C: 032] "Apparently yes for now, per IRC." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106480 (owner: 10Gergő Tisza)
[18:33:01] <marktraceur>	 'kay, both criticals in
[18:33:33] <grrrit-wm>	 (03Merged) 10jenkins-bot: Fix metadata loading [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106480 (owner: 10Gergő Tisza)
[18:49:15] <aarcos>	 marktraceur: I do have +2 for MMV but I wasn't sure about the timing that's why I deferred to you, ;-). I don't have +2 for UploadWizard though, that would be nice to have. Getting dinner now, seeya guys tomorrow !...
[18:49:28] <marktraceur>	 'kay, I'll propose that as well
[19:24:40] <grrrit-wm>	 (03PS1) 10Gilles: Improve the test coverage to also check prev/next scroll [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106560 
[19:26:28] <gi11es>	 shouldn't we have a gerrit group to add the whole team easily as reviewers?
[19:26:37] <gi11es>	 right now the "multimedia" group on gerrit is just robla
[19:26:56] <marktraceur>	 Hah
[19:27:14] <robla>	 heh....not sure for Gerrit purposes that I should even be in that group
[19:27:19] <marktraceur>	 "yes" but the team won't necessarily be good for every change
[19:27:33] <robla>	 that too
[19:27:42] <gi11es>	 it'd be a useful shortcut for what we write ourselves, imho
[19:27:48] <gi11es>	 I don't mean that it should be automatic at all
[19:28:01] <gi11es>	 just that we have the option to autocomplete to multimedia team without having to add each person manually
[20:14:27] <marktraceur>	 We are live on mw.org
[20:54:30] <marktraceur>	 tgr: So did you want to take a crack at the caching issue, or should I?
[20:54:45] <marktraceur>	 I would not mind backporting it today if we can pull it off
[20:57:12] <grrrit-wm>	 (03PS1) 10Gergő Tisza: Do not re-request repoinfo [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106620 
[20:57:25] <fabriceflorin>	 marktraceur tgr : Is there anything in particular I should be looking at as I test Media Viewer on MediaWiki now?
[20:57:40] <tgr>	 marktraceur: I think ^^ restores original behavior
[20:57:56] <tgr>	 I have to admit I don't really understand it though
[20:58:54] <tgr>	 shouldn't it be backwards, that we call repoinfo if this.imageinfo[filename] is missing, and imageinfo otherwise?
[20:59:34] <tgr>	 anyway I still want to revisit this after promises are in
[20:59:56] <tgr>	 there are a lot of concurrency bugs now that will become easier to handle
[21:00:18] <tgr>	 especially when you page around without waiting for calls to finish
[21:00:40] <tgr>	 just pressing left and right wildly for a few secs crashes chrome right now
[21:00:46] <marktraceur>	 tgr: No, imageinfo is information about the repo, if we're only missing that then we get only that. But that's outdated code, I think - I didn't know what I was saying when I wrote that
[21:00:59] <marktraceur>	 I'll do the promises thing first then
[21:06:25] <marktraceur>	 tgr: Why not just always call...wait
[21:06:47] <marktraceur>	 tgr: We probably broke resize again with this patch actually
[21:06:53] <marktraceur>	 OK, promises, then I'll fix this
[21:06:57] <marktraceur>	 And comment it heavily
[21:17:40] <marktraceur>	 tgr: I don't think I can use returns necessarily, because I've built this (erroneously) to run on two requests
[21:17:45] <marktraceur>	 I'm going to "just" change that
[21:18:24] <marktraceur>	 In fact
[21:18:33] <marktraceur>	 I'll just start caching the promises right away, it's way simpler then
[21:21:47] <tgr>	 i agree thats the best way
[21:22:19] <tgr>	 avoids all the possible breakages that could happen if the request is triggered again before it has finished
[21:22:24] <marktraceur>	 Yup
[21:22:37] <marktraceur>	 I don't think then is the best way though
[21:23:14] <tgr>	 I think it's easier to read
[21:23:24] <marktraceur>	 Well
[21:23:37] <marktraceur>	 But for one of these cases I will have two promise objects I need to resolve before calling back
[21:23:49] <tgr>	 takes a bit getting used to, but it basically translates concurrent code into single-thread syntax
[21:24:29] <tgr>	 you can use $.when(promiseA, promiseB).then(function(resA, resB))
[21:24:39] <marktraceur>	 I think I read code of yours using promises and then() and it wasn't going to do what you intended
[21:24:44] <marktraceur>	 The UploadWizard patch maybe
[21:24:59] <marktraceur>	 OH
[21:25:00] <marktraceur>	 Wait
[21:25:04] <marktraceur>	 I did not know this
[21:25:06] <marktraceur>	 Holy crap
[21:25:08] <marktraceur>	 Life is awesome
[21:25:31] <marktraceur>	 I get what you're saying now, you can return promise objects from a then() callback
[21:25:55] <tgr>	 yeah, promises are awesome
[21:26:15] <tgr>	 jquery promises are slightly flawed but still awesome
[21:28:52] <marktraceur>	 Hm, but it maybe modifies the object
[21:29:05] <marktraceur>	 I guess that's OK
[21:29:06] <marktraceur>	 Ignore me
[21:35:52] <marktraceur>	 This is actually pretty cool
[21:35:58] <marktraceur>	 Let me test it, hammer it out, and we'll see
[21:36:10] <marktraceur>	 I removed the repoInfo thing, it should just be batched with any image request that goes out
[21:42:58] <quiddity>	 fabriceflorin, on [[Commons:Multimedia Features/Vision 2016]] - I'm not sure if you'd prefer a TOC floated out of the way, or no TOC at all.  I've implemented the former, and left instructions on the latter in the edit-summary:
[21:42:59] <quiddity>	 https://commons.wikimedia.org/w/index.php?title=Commons:Multimedia_Features/Vision_2016&diff=113554731&oldid=113516743
[21:43:33] <grrrit-wm>	 (03CR) 10Gergő Tisza: [C: 031] "Works fine, although feels less elegant to me. (I suppose this is a Mac problem? Firefox on Windows or Linux doesn't do anything special w" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106224 (owner: 10Gilles)
[21:44:54] <marktraceur>	 tgr: Hm, it looks like .then() with a promise return value doesn't overwrite the resolution like I hoped it would
[21:45:35] <tgr>	 pretty sure that works
[21:46:00] <tgr>	 just keep in mind the syntax is .then(resolveHandler, rejectHandler)
[21:46:03] <marktraceur>	 It looks like the api promise is calling the callback with the api return value, not with the filtered value I give it back in apiCallback
[21:46:07] <marktraceur>	 Yeah
[21:46:42] <tgr>	 the promise is not affected at all by then
[21:46:50] <marktraceur>	 Oh, because I'm dumb
[21:46:53] <tgr>	 but then returns a new promise, and that one is affected
[21:46:59] <marktraceur>	 I should stop saying words and just read my dumb code
[21:47:08] <fabriceflorin>	 quiddity: Thanks so much for offering to help with this, I'm such a newbie! I like what you've done, it's very elegant -- and effectively addresses my issue with not having the contents in your face when you're just trying to read the page. Merci beaucoup! :)
[21:47:23] <marktraceur>	 Seems to be working
[21:48:04] <quiddity>	 nay problem, just another tiny wikignoming task, as I add things to my watchlists :)
[21:49:01] <marktraceur>	 tgr: I think the next step is to have a better structure, internally, for image information
[21:49:57] <marktraceur>	 mmv.dm
[21:50:30] <tgr>	 I would be in favor of agressively separating UI, behavior, data and persistence logic
[21:50:40] <fabriceflorin>	 Just added a credit to Quiddity on the Multimedia Vision for being one of our favorite guardian angels :)
[21:50:53] <marktraceur>	 Fun times
[21:50:58] <marktraceur>	 I'll make that patch...let's see
[21:51:01] <marktraceur>	 I guess after this
[21:51:07] <tgr>	 so have a bunch of value objects which contain only data and no nontrivial logic and can be used without concerns in tests
[21:51:32] <marktraceur>	 Possibly interrupted by an LD
[21:51:34] <tgr>	 have some services which are immutable apart from caching, and store/fetch the models
[21:52:03] <tgr>	 have some objects which only deal with interface creation
[21:52:20] <tgr>	 and a controller which binds them together via pubsub or something like that
[21:53:25] <marktraceur>	 Sounds good to me
[21:53:54] <marktraceur>	 The controller can be relatively dumb, it just interfaces with both, I like that plan
[21:55:23] <grrrit-wm>	 (03PS2) 10MarkTraceur: Use promises [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106004 
[21:55:24] <grrrit-wm>	 (03CR) 10jenkins-bot: [V: 04-1] Use promises [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106004 (owner: 10MarkTraceur)
[21:55:30] <marktraceur>	 Fun times: 28 lines of code down
[21:55:32] <marktraceur>	 OH COME ON
[21:57:32] <grrrit-wm>	 (03PS3) 10MarkTraceur: Use promises [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106004 
[21:57:34] <marktraceur>	 27
[21:57:37] <marktraceur>	 Whatever
[22:28:39] <marktraceur>	 tgr: Able to review that? :)
[22:28:47] <tgr>	 looking at it already
[22:32:57] <marktraceur>	 Coolio
[23:00:55] <grrrit-wm>	 (03CR) 10Gergő Tisza: [C: 04-1] "A few issues. The big ones are those in the three-pronged if." (037 comments) [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106004 (owner: 10MarkTraceur)
[23:03:55] <marktraceur>	 tgr: .promise() is for code security; people shouldn't be rejecting or resolving returned promises
[23:04:18] <tgr>	 it wouldn't hurt
[23:04:44] <tgr>	 once a deferred is resolved/rejected, any further attempt is a noop
[23:05:16] <marktraceur>	 Hm, maybe that's true then
[23:06:02] <tgr>	 so calling promise() is a good habit in general, but right after a reject/resolve it is unnecessary
[23:08:22] <marktraceur>	 Right
[23:08:49] <marktraceur>	 'kay, that's done
[23:08:55] <marktraceur>	 (after wrong-channeling twice)
[23:09:21] <marktraceur>	 I will also push things out of apiCallback and into properly-named functions, whee
[23:27:05] <grrrit-wm>	 (03CR) 10MarkTraceur: "New patchset incoming" (037 comments) [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106004 (owner: 10MarkTraceur)
[23:27:23] <grrrit-wm>	 (03PS4) 10MarkTraceur: Use promises [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/106004 
[23:52:23] <marktraceur>	 Right, next up: Data model change