[00:33:08] <wikibugs>	 3MediaWiki extensions / 3CommonsMetadata: License detection logic is inconsistent - 10https://bugzilla.wikimedia.org/60650#c1 (10Tisza Gergő) 5ASSI>3RESO/FIX Fixed by the work done in bug 57259; we ignore categories now.
[00:40:07] <wikibugs>	 3MediaWiki extensions / 3MultimediaViewer: Media Viewer should display the "Credit" parameter when available - 10https://bugzilla.wikimedia.org/65445#c4 (10Tisza Gergő) Tracked in https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/674
[00:55:52] <wikibugs>	 3MediaWiki extensions / 3CommonsMetadata: No proper handling of multivalued fileds - 10https://bugzilla.wikimedia.org/57259#c10 (10Tisza Gergő) 5PATC>3UNCO All examples from this and duplicate tickets provide correct data now. Is anyone aware of images which are still showing inconsistent licence informa...
[04:44:54] <wikibugs>	 3MediaWiki extensions / 3PagedTiffHandler: Fatal error: Access level to PagedTiffHandler::visibleMetadataFields() must be public - 10https://bugzilla.wikimedia.org/64224 (10dan) 5PATC>3RESO/FIX
[06:13:12] <grrrit-wm>	 (03PS1) 10Legoktm: Don't use deprecated IContextSource::getLang [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/139774 
[06:39:35] <grrrit-wm>	 (03PS1) 10Gilles: Don't query tables that have only data older than 30 days [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/139780 
[07:59:38] <wikibugs>	 3MediaWiki extensions / 3MultimediaViewer: Expand View button broken on IE10 - 10https://bugzilla.wikimedia.org/66245#c1 (10Tisza Gergő) Seems to be this IE10 bug: http://stackoverflow.com/questions/17944354/svg-background-image-position-is-always-centered-in-internet-explorer-despite-b  When I replace the S...
[08:46:44] <grrrit-wm>	 (03CR) 10Gilles: [C: 04-1] "Mingle card?" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/138303 (owner: 10Gergő Tisza)
[08:49:15] <grrrit-wm>	 (03CR) 10Gilles: "Have you tried it with a screen reader? I'm pretty sure that they'd respect CSS visibility (and thus not read that text out loud)." [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/110310 (owner: 10Brian Wolff)
[08:55:55] <wikibugs>	 3MediaWiki extensions / 3CommonsMetadata: CommonsMetadata outputs values with trailing « &#10 » - 10https://bugzilla.wikimedia.org/66652 (10Jean-Fred) 3NEW p:3Unprio s:3minor a:3None While fishing for suspects in bug 57259, I came across this issue with this image:  https://commons.wikimedia.org/w/ap...
[08:57:22] <grrrit-wm>	 (03CR) 10Gilles: [C: 04-1] Only do pop up video player if we actually have a bigger size (031 comment) [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/138307 (owner: 10Brian Wolff)
[09:12:38] <grrrit-wm>	 (03CR) 10Gilles: [C: 04-1] "Works fine, verified on IE8, 9, 10 and 11 on saucelabs. You just need to remove the dependency on jquery.client currently defined for mmv." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/134655 (owner: 10MarkTraceur)
[09:12:56] <grrrit-wm>	 (03CR) 10Gilles: "Also, please add a reference to a mingle card." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/134655 (owner: 10MarkTraceur)
[09:14:14] <grrrit-wm>	 (03CR) 10Gilles: [C: 032] Fix js bug where error report was always for first link. [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/108172 (owner: 10Brian Wolff)
[09:14:21] <grrrit-wm>	 (03Merged) 10jenkins-bot: Fix js bug where error report was always for first link. [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/108172 (owner: 10Brian Wolff)
[09:15:34] <thedj>	 gi11es: got a JS error on MMV view original
[09:15:39] <thedj>	 https://en.wikipedia.org/wiki/Linux_distributions#mediaviewer/File:Linux_Distribution_Timeline.svg
[09:16:05] <thedj>	 TypeError: 'undefined' is not an object (evaluating 'mw.config.get(
[09:16:08] <thedj>	 'wgFormattedNamespaces')[this.namespace].replace')
[09:18:03] <thedj>	 http://pastebin.com/xjhMxQsR
[09:20:18] <thedj>	 has to do with namespaces now known to the local wiki
[09:23:10] <wikibugs>	 3MediaWiki extensions / 3MultimediaViewer: MMV crashes on fileUsage array if namespace is unknown on local wiki - 10https://bugzilla.wikimedia.org/66657 (10Derk-Jan Hartman) 3NEW p:3Unprio s:3normal a:3None https://en.wikipedia.org/wiki/Linux_distributions?debug=true#mediaviewer/File:Linux_Distributi...
[09:30:33] <grrrit-wm>	 (03CR) 10Gilles: [C: 032] Revert "Use localized namespace name in embed wikitext" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/131509 (https://bugzilla.wikimedia.org/64710) (owner: 10Gergő Tisza)
[09:31:08] <grrrit-wm>	 (03Merged) 10jenkins-bot: Revert "Use localized namespace name in embed wikitext" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/131509 (https://bugzilla.wikimedia.org/64710) (owner: 10Gergő Tisza)
[09:33:23] <wikibugs>	 3MediaWiki extensions / 3MultimediaViewer: MMV crashes on fileUsage array if namespace is unknown on local wiki - 10https://bugzilla.wikimedia.org/66657#c1 (10Derk-Jan Hartman) If you are doing crosswiki links, you should really implement a JS function that can guarantee the same behavior as PHPs Title::make...
[09:34:58] <grrrit-wm>	 (03CR) 10Gilles: [C: 031] Fix URL handling for global usage list [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/138999 (https://bugzilla.wikimedia.org/63908) (owner: 10Gergő Tisza)
[09:35:50] <grrrit-wm>	 (03CR) 10TheDJ: "Of note, bug 66657 is also running into a problem due to missing makeTitle support, but for formatting interwiki links." [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/139592 (https://bugzilla.wikimedia.org/66366) (owner: 10Rillke)
[09:39:24] <wikibugs>	 3MediaWiki extensions / 3MultimediaViewer: TypeError: mw.config.get(...)[this.namespace] is undefined - 10https://bugzilla.wikimedia.org/66147#c3 (10Derk-Jan Hartman) *** Bug 66657 has been marked as a duplicate of this bug. ***
[09:39:25] <wikibugs>	 3MediaWiki extensions / 3MultimediaViewer: MMV crashes on fileUsage array if namespace is unknown on local wiki - 10https://bugzilla.wikimedia.org/66657#c2 (10Derk-Jan Hartman) 5NEW>3RESO/DUP   *** This bug has been marked as a duplicate of bug 66147 ***
[09:44:36] <grrrit-wm>	 (03CR) 10Gilles: [C: 032] Updated chevron icons [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139020 (owner: 10Pginer)
[09:45:11] <grrrit-wm>	 (03Merged) 10jenkins-bot: Updated chevron icons [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139020 (owner: 10Pginer)
[09:46:06] <grrrit-wm>	 (03CR) 10TheDJ: "If there is reason for immediacy I can support this, but i think it is better to add this to mw.Title itself." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/138999 (https://bugzilla.wikimedia.org/63908) (owner: 10Gergő Tisza)
[09:47:55] <grrrit-wm>	 (03CR) 10Gilles: [C: 04-1] "Break this down into a bunch of smaller commits, please, it makes review needlessly difficult the way it currently is. The profusion of bu" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139267 (owner: 10Gergő Tisza)
[09:51:03] <grrrit-wm>	 (03CR) 10Gilles: [C: 04-1] "Typo in commit message's title, feel free to +2 once fixed." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139572 (owner: 10Gergő Tisza)
[09:51:08] <wikibugs>	 3MediaWiki / 3Uploading: JSON File upload not working: "File ending .json does not fit MIME type (text/plain)" - 10https://bugzilla.wikimedia.org/66036#c1 (10Andre Klapper) p:5Unprio>3Normal Hi, does the file "mime.types" list     text/plain json ?  See https://www.mediawiki.org/wiki/Manual:Mime_type_det...
[09:51:23] <wikibugs>	 3MediaWiki extensions / 3MultimediaViewer: Embed should use localized wikitext - 10https://bugzilla.wikimedia.org/64710#c9 (10Nemo) (In reply to Gerrit Notification Bot from comment #8) > Change 131509 merged by jenkins-bot: > Revert "Use localized namespace name in embed wikitext"  I'm confused. What change...
[10:01:51] <grrrit-wm>	 (03CR) 10Gilles: [C: 032] Don't use deprecated IContextSource::getLang [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/139774 (owner: 10Legoktm)
[10:03:17] <grrrit-wm>	 (03Merged) 10jenkins-bot: Don't use deprecated IContextSource::getLang [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/139774 (owner: 10Legoktm)
[10:03:23] <wikibugs>	 3MediaWiki / 3File management: GIMP file format images display green instead of B&W - 10https://bugzilla.wikimedia.org/66323#c6 (10Derk-Jan Hartman) Upstream reports this fixed in ImageMagick 6.8.9-3 Beta
[11:50:27] <gi11es>	 thedj: is it in bugzilla or should I add it?
[12:10:11] <grrrit-wm>	 (03PS1) 10Gilles: Add Safari to browser tags [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139811 
[14:20:47] <thedj>	 gi11es: already added and closed as dupe of 66147
[15:05:24] <wikibugs>	 3MediaWiki / 3Uploading: Uppercase picture extensions like .PNG are not allowed - 10https://bugzilla.wikimedia.org/66667#c1 (10Andre Klapper) With which browser(s) was this tested?  I also wonder if adding    image/png PNG to mime.types would change anything; see https://www.mediawiki.org/wiki/Manual:MIME_ty...
[15:20:39] <wikibugs>	 3MediaWiki / 3Uploading: Uppercase picture extensions like .PNG are not allowed - 10https://bugzilla.wikimedia.org/66667#c2 (10vidarsk) Tested in FireFox. I doubt mime.types would help, unless there's some magic there that causes it to skip the parameter test in IEUrlExtension.php. When I try to open the pic...
[16:13:54] <wikibugs>	 3MediaWiki / 3File management: Allow different declaration of svg fonts - 10https://bugzilla.wikimedia.org/23643 (10PRO)
[16:28:46] <gi11es>	 thedj: thanks
[17:06:09] <rillke>	 bd808, hi,  how long do new project requests usually need to be processed by someone?
[17:07:12] <bd808>	 rillke: "It depends". Coren is out on vacation right now so there is at least one fewer person processing the queue.
[17:07:21] <bd808>	 When did you put the request in?
[17:07:33] <rillke>	 2 days ago
[17:09:36] <rillke>	 but it was weekend of course; do you have time right now talking about the MediaHandler?
[17:11:49] <bd808>	 rillke: If you don't have a project by tomorrow you could gently whine at andrewbogott in #wikimedia-labs 
[17:12:21] <rillke>	 okay, bd808
[17:13:05] <bd808>	 I'm in the middle of writing some emails to catch up from my vacation last week right now. I should have time to chat tomorrow if that works for you.
[17:13:39] <bd808>	 Or send email and bawolff might answer before I get time to look at your questions. :)
[17:13:44] <rillke>	 yeah, of course, I don't run out of work :) Thank you
[17:14:15] <rillke>	 bawolff, he wrote he would have time at 17:00 utc but now I am looking for him --- perhaps a misunderstanding
[17:14:54] <bd808>	 College kids. ;)
[17:40:42] <grrrit-wm>	 (03CR) 10Gergő Tisza: [C: 04-1] "It would make more sense to me to add something like" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139811 (owner: 10Gilles)
[17:48:41] <marktraceur>	 tgr, gi11es - I think I need to reschedule the refactor planning meeting again, because I fail at calendars. But also maybe this can just be a Multimedia-l thread
[17:49:47] <tgr>	 if we are pushing UW back, it might make sense to do it in the next cycle anyway
[17:50:13] <tgr>	 a mailing list thread sounds fine to me, too
[17:50:49] <tgr>	 a meeting after we have identified any hard questions is probably more productive than one before it
[17:52:22] <wikibugs>	 3MediaWiki / 3Uploading: Uppercase picture extensions like .PNG are not allowed - 10https://bugzilla.wikimedia.org/66667#c3 (10Bawolff (Brian Wolff)) Mime.types wouldnt affect this
[17:52:47] <marktraceur>	 Sure
[17:52:59] <marktraceur>	 tgr: I'll draft something with all of my head-floating ideas about refactoring UW
[17:53:50] * marktraceur is attempting in vain to catch up with his email
[17:59:11] <grrrit-wm>	 (03CR) 10Gergő Tisza: "@TheDJ: Comparisons with server-side which functions are not necessarily realistic; also, that function looks conceptually broken to me (f" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/138999 (https://bugzilla.wikimedia.org/63908) (owner: 10Gergő Tisza)
[18:00:52] <grrrit-wm>	 (03PS2) 10Gergő Tisza: Fix description of date messages [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139572 
[18:01:07] <grrrit-wm>	 (03CR) 10Gergő Tisza: [C: 032] Fix description of date messages [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139572 (owner: 10Gergő Tisza)
[18:01:43] <grrrit-wm>	 (03Merged) 10jenkins-bot: Fix description of date messages [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139572 (owner: 10Gergő Tisza)
[18:06:02] <thedj>	 Krinkle: what do you think about mw.Title for non local wikis ? https://gerrit.wikimedia.org/r/138999
[18:06:07] <thedj>	 archetectually speaking.
[18:07:58] <thedj>	 i think the last time we had a discussion about this API + mw.title it was concluded to simply not use mw.Title at all...
[18:08:44] <Krinkle>	 thedj: this IwTitle class doesn't seem to do anything. It takes everytihng as arguments
[18:09:05] <Krinkle>	 so intuitively I'd say making classes for this is Java-like over engineering.
[18:09:11] <grrrit-wm>	 (03CR) 10Gergő Tisza: "We use Mingle to schedule how we spend our work hours and to plan complex features; this is a very simple change (doing it probably took l" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/138303 (owner: 10Gergő Tisza)
[18:09:15] <Krinkle>	 there is likely an object already with these properties and should just use that as-is
[18:09:30] <thedj>	 url builder
[18:09:41] <Krinkle>	 Nope
[18:10:04] <thedj>	 Krinkle: i think the problem partly comes from wanting to display the title stripped from the namespace.
[18:10:32] <Krinkle>	 thedj: architecturally I'd say a class should not pretend to provide something it can't. Unless we add various APIs and http calls, a javascript class can never be non-broken. Because lots of normalisation rules are dependent on config.
[18:10:36] <Krinkle>	 Yep
[18:10:56] <Krinkle>	 thedj: but as-is that patch commits a class that does nothing related to the foreign wiki, not even building url or separating namespace prefix.
[18:11:19] <tgr>	 hah
[18:11:23] <Krinkle>	 which means it is already computed elsewhere
[18:11:29] <Krinkle>	 and that object is probably the object you want to use then
[18:11:42] <tgr>	 you should have seen my plans to add an IwTitleFactoryFactory
[18:12:18] <tgr>	 anyway, currently adding a class is the only way to have an object with well-defined properties
[18:12:45] <tgr>	 there are documentation frameworks which can do that for a plain object, but jsduck cant
[18:13:19] <Krinkle>	 Well, writing documentation can never ever justify adding classes and overhead imho.
[18:13:32] <Krinkle>	 First and foremost becuase jsduck explicitly supports faux classes for this reason
[18:13:39] <tgr>	 sure it can
[18:14:01] <tgr>	 having documentation is the pretty much only reason value objects are useful
[18:14:06] <tgr>	 value object classes I mean
[18:14:15] <Krinkle>	 Fore example  like https://github.com/wikimedia/mediawiki-core/blob/master/maintenance/jsduck/external.js  and https://github.com/senchalabs/jsduck/blob/master/js-classes/Number.js
[18:14:18] <Krinkle>	 require no actual javascript
[18:14:31] <tgr>	 but if jsduck does support faux classes, that would be fine as well
[18:14:34] <Krinkle>	 so if you really just want to document, then do that.
[18:14:36] <tgr>	 I missed that then
[18:14:51] <Krinkle>	 we do the same with jQuery.Promise as well
[18:15:14] <Krinkle>	 Though that could be improved, I'd like to document its methods as well.
[18:17:40] <Krinkle>	 It seems you have an additional use case, which is passing it around for method calls.
[18:17:54] <Krinkle>	 eg. you're not passing it so you have an object with a .url property, but so you have an object with a getUrl method.
[18:17:59] <tgr>	 well, jQuery.Promise or Number are not faux classes, they are real classes with faux (or rather external) documentation
[18:18:11] <marktraceur>	 Heh, tgr, weren't you grumbling about replacing jQuery.Promise anyway? ;)
[18:18:35] <tgr>	 Krinkle: basically I wanted something that could be dropped in the place of a mw.Title object
[18:18:51] <Krinkle>	 Sounds like maybe you want a faux interface (a subset of mw.Title), and use that as typehint for where you expect mw.Title and iwtitlte
[18:19:00] <Krinkle>	 or alternatively, call the method before passing the data
[18:19:13] <Krinkle>	 so that the interfaces communicate with 'url' instead of 'object which I'll call getUrl on'
[18:19:17] <tgr>	 the class which links to a page should not need to know whether it is a local page, they are displayed almost identically
[18:19:25] <Krinkle>	 lots of ideas.
[18:19:36] <Krinkle>	 I'll leave you to it.
[18:22:46] <marktraceur>	 tgr: https://github.com/kriskowal/q does look pretty neat
[18:23:32] <tgr>	 marktraceur: I wasn't serious about that
[18:23:45] <marktraceur>	 Heh
[18:23:46] <tgr>	 yeah, it would be cool to use Q or bluebird promises
[18:24:27] <tgr>	 but jQuery promises are deeply integrated with other jQuery functions like $.ajax or $.animate
[18:24:45] <marktraceur>	 Hm, true
[18:24:51] <tgr>	 there is no way to replace that, and having two kinds of promises would be total chaos
[18:25:18] <marktraceur>	 As opposed to other things we do
[18:25:32] <Krinkle>	 I have plans for OOjs to utilize the native Promise interface coming soon in browsers. The polyfil would use jQuery.Deferred().promise() as its fallback.
[18:25:33] <tgr>	 especially considering that the reason to not use jQuery's implementation in the first place would be that it does not implement the standard properly
[18:26:25] <Krinkle>	 "the standard" is most controversial. what-wg's been discussing it for over a year now. I'm involved in that discussion from both what-wg and jQuery team.
[18:26:32] <Krinkle>	 CommonJS means nothing
[18:26:55] <tgr>	 Krinkle: that sounds cool. But as I said, keep in mind, jQuery does not implement Promises/A(+) properly
[18:27:24] <Krinkle>	 I'm saying Promises/A means nothing. That's just one of many standards. By no means "the" standard, at all. Just something someoe wrote and claimed it to be the A standard.
[18:27:24] <tgr>	 yeah, I guess it is not entirely fair to call it a standard
[18:27:40] <Krinkle>	 even commonjs itself has multiple promise standards
[18:27:41] <tgr>	 still it is the way pretty much every other promise library works
[18:27:45] <Krinkle>	 (hence the /A part)
[18:28:07] <Krinkle>	 And jQuery does match it as close as they deem fair
[18:28:30] <Krinkle>	 The deviations are either for back-compat or for rational disagreements about how things should be handled. 
[18:28:53] <Krinkle>	 Last discussion was in April last year in Amsterdam. The main turning point at the moment was error handling.
[18:28:58] <tgr>	 as soon as your functions start throwing exceptions, the jQuery implementation will behave differently in very significant ways
[18:29:04] <Krinkle>	 Swallowing exceptions
[18:29:16] <Krinkle>	 Indeed.
[18:30:10] <tgr>	 also, the way they handle rejection handlers returning rejections is the exact opposite
[18:30:49] <Krinkle>	 At this point I'd say the only defacto "standard" is having .then( done callback | null, fail callback | null)
[18:31:05] <Krinkle>	 anything else is "depends", including the pipe behaviour and chaining.
[18:32:13] <tgr>	 well, the point is, if something either uses a native promise object or the jQuery version depending on the browser, then those two should have the exact same behavior otherwise things will get ugly
[18:34:01] <tgr>	 my impression is, jQuery devs are not really conscious of this issue
[18:34:45] <tgr>	 they don't have proper documentation, you have to read the code to figure out how a promise object behaves in most cases
[18:35:06] <tgr>	 like the return types of then
[18:35:46] <tgr>	 which is another fun topic, jQuery promises have multiple "return values", in somewhat inconsistent ways
[18:36:29] <tgr>	 if any replacement is not fully compatible with that -> chaos
[18:39:26] <grrrit-wm>	 (03CR) 10Gergő Tisza: "Note that this will cause weirdness if the follow-up patch is not merged within the same branch." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139020 (owner: 10Pginer)
[18:41:11] <grrrit-wm>	 (03CR) 10Gergő Tisza: "For reference, the discussion about this was at http://lists.wikimedia.org/pipermail/multimedia/2014-May/000402.html (with no clear outcom" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/131509 (https://bugzilla.wikimedia.org/64710) (owner: 10Gergő Tisza)
[18:47:39] <grrrit-wm>	 (03Abandoned) 10Gergő Tisza: Make the metadata panel opening affordance more obvious [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139267 (owner: 10Gergő Tisza)
[18:48:13] <marktraceur>	 Down to 250 unread mails....sigh
[18:55:41] <marktraceur>	 Hahaha done
[18:55:44] <marktraceur>	 Now I can write some
[19:07:39] <fabriceflorin>	 marktraceur gi11es tgr: Hi guys, I just took a closer look at the tablet issues which people were reporting over the weekend and have a better understanding of what’s causing their problem: when they pinch/zoom or scroll on the image, the info bar takes over the screen; I have an iPad on my desk if you want to see that behavior. To that end, I have filed this ticket #716, which I recommend we take on this week: 
[19:07:40] <fabriceflorin>	 https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/716 
[19:32:05] <marktraceur>	 fabriceflorin: "this week" as in before Wednesday?
[19:32:28] <marktraceur>	 (also, this conversation is ten times better on IRC)
[19:35:49] <fabriceflorin>	 marktraceur: I think it’s an important issue, but don’t know if it can be solved by Wednesday, until you guys estimate it. So when I wrote ‘this week’ I was thinking of the entire week. For now, I added to this current cycle a couple important but easy tickets (#714) qnd #715) that were estimated low and could be done by Wednesday: http://ur1.ca/gtyrp
[19:36:29] <fabriceflorin>	 Glad that IRC works better for these types of discussions. Will try to use it more :)
[19:36:43] <marktraceur>	 OK if it's important but not vital, I would suggest adding it to "next sprint"
[19:36:46] <marktraceur>	 Because that's what it is
[19:36:59] <marktraceur>	 If we run out of stuff to do this sprint, we'll go to next sprint and pull things in
[19:37:27] <marktraceur>	 And then you don't need to ping all three of us just to keep track of it, because the issue tracker we use can actually track the issues
[19:40:51] <fabriceflorin>	 marktraceur: Note that I did not add #716 to the current sprint, because I think it could wait until the next sprint, as you suggest. But it would be great if you guys could estimate it, and find out what it would take to address it. For now, I recommend #714 and #715 as low hanging fruits that will help measure the impact our work is having on our community. 
[19:41:09] <marktraceur>	 We will estimate it as a team on Wednesday
[19:41:14] <marktraceur>	 Because protocol semantics
[19:41:29] <marktraceur>	 Unless this is red-alert-do-it-now urgent, that is.
[19:43:04] <fabriceflorin>	 marktraceur: No it’s not red-alert, but keep it in mind, so we can move quickly in the next sprint (e.g. a quick chat with mobile team that may know how to fix would be worthwhile, while you’re still in the office).
[19:43:30] <marktraceur>	 That's what the tracker is for
[19:43:53] <marktraceur>	 And no, I don't need to talk to the mobile team, the Internet also knows things about mobile gesture events
[20:34:38] <wikibugs>	 3MediaWiki / 3Uploading: Upload broken after upgrade to 1.23 - 10https://bugzilla.wikimedia.org/66467#c6 (10nuess0r) I'm one of this users who has problems with uploads after the upgrade (http://www.mediawiki.org/w/index.php?title=Project:Support_desk&offset=20140613133023&limit=20#image.2Ffile_upload_broken...
[21:30:14] <marktraceur>	 Gorram it, I hate it when I fail to notice a card needs design work
[21:55:00] <tgr>	 there are good libraries for mobile gestures (jQuery Mobile would be the obvious one), but given that tablets are being redirected to the mobile site, do we really want to spend time on this?
[21:55:18] <marktraceur>	 The mobile site gets MMV too....right?
[21:55:27] <tgr>	 not as far as I know
[21:56:01] <tgr>	 they have their own viewer, which is just a standard lightbox without any information, and about twenty times smaller
[21:56:11] <marktraceur>	 Hm
[21:56:28] <tgr>	 size was the main problem they had with MMV
[21:56:31] <marktraceur>	 Well, then maybe that's not a big issue
[21:56:34] <tgr>	 they being the mobile team
[21:56:44] <marktraceur>	 fabriceflorin: Given the impending doom of the tablets-as-desktops era, do we care?
[21:58:00] <tgr>	 as for zoom, IMO it would become a horrible time sink
[21:58:25] <tgr>	 messing with browser zoom today is like messing with cross-domain communication was in the pre-CORS era
[21:58:31] <fabriceflorin>	 marktraceur: Yeah, that’s why I put this on a slower track. But I think we still care, because some tablet users will continue to use the desktop version. And the deployment could be delayed. In any case, it makes it less urgent, though still worth looking into.
[21:58:33] <tgr>	 hacks upon hacks upon hacks
[21:59:39] <fabriceflorin>	 Note that MMV will not be implemented on mobile any time soon. This is likely to require a lot of tender loving care in Q3.
[22:03:38] <marktraceur>	 https://www.youtube.com/watch?feature=player_detailpage&v=fpQXYHt7Mxc#t=30 (hacks on hacks on hacks)
[22:11:07] <wikibugs>	 3MediaWiki extensions / 3UploadWizard: UploadWizard blocks upgrade when used with PostgreSQL - 10https://bugzilla.wikimedia.org/64067#c4 (10Jeff Janes) The fix is merged into git, but UploadWizard does not seem to have tarball releases anymore and so the fixed code must be obtained from git.  Does that mean...