[00:26:47] kaldari_: hey [00:26:55] howdy [00:27:45] The flickr uploader works great. Did you have any thoughts about creating a new user right for it? [00:32:16] ya it would be good to create a new right [00:32:38] but we should make it generic I guess, like for any 3rd party upload [00:33:36] drecodeam: sounds reasonable, although I think it should correlate to some sort of whitelist of approved sites [00:35:32] ya that would be better [00:37:34] kaldari: I am also done with the photoset/album upload. Just making some final touches before patching it [00:37:45] maybe 'upload_by_whitelisted_url' [00:37:55] awesome [00:38:23] are there any things you need help with? [00:39:38] Ya there are a few things... mostly conceptual. One, the process that I have taken right now is that at no point you can edit the Flickr License information [00:39:51] that is the correct approach right ? [00:40:24] ( If there are only flickr uploads, then the deeds step is skipped altogether ) [00:40:47] yes, I think that is appropriate [00:41:57] they can always change the licensing info after the images are uploaded if needed [00:44:10] but if we allow them to change the license in the middle of the process, we'd have to redo the license validation part and I think it would add unnecessary complexity to the interface. [00:44:51] I like the idea of treating it more like an automated importing function [00:45:08] but others may disagree :) [00:46:01] keep in mind, that whatever you create on Wikipedia, someone will complain about it, so don't try to please everyone. It's impossible :) [00:47:07] but try to balance requested features with simple, useable UI design [00:47:07] I guess its more intuitive even for the user for the automated process [00:48:23] kaldari: ya you are right, and we can always add a change license option in the details step, if at all that feature is really needed [00:48:54] It would be like the current interface only, when we choose the option of adding license individually to files [00:49:37] So I guess I would leave it like this for now, and add the feature if needed later [00:50:46] It seems like it might be a reasonable possibility at some point, but it would definitely add some complexity (and make license verification messy). I would suggest keeping it how you have it for now. [00:51:06] ok [00:51:48] off to the other problem : Lupo suggested me in moving the Flickr API calls to the server side and then expose them through an API [00:52:15] what do you think about this ? [00:53:07] That would probably be fine, and it would let other people incorporate it into their tools as well. We would probably need to add some throlling to it though to prevent abuse. [00:53:48] although that can be added later [00:54:41] what advantages does server side calls have over javascript ones ? [00:55:10] it's more reusable, especially for non-mediawiki tools, like bots and toolserver scripts... [00:55:41] although in this case I don't see a huge advantage since it would basically just be a proxy for flickr's API anyway [00:55:56] or rather a wrapper around it [00:57:30] In that case, I guess it can be done later so I would not work on it as of now [00:57:36] the downside is that it would be slower for us [00:58:04] since we would be calling an API that calls another API [00:58:38] yeah, I don't think it sounds like a priority [00:59:18] but if other tool-builders express interest, it might be worth looking into [00:59:24] at some point [01:00:04] ya, but then if tool builders show interest, it would not be related to Upload Wizard [01:00:13] true [01:00:22] maybe it could be a separate project [01:00:37] for next year :) [01:01:05] anyway, I'm about to head home. Any other issues before I run? [01:01:17] yes one thing... in my midterm evaluations [01:01:44] there is a question asking for "how often do you interact with the mentor" [01:02:26] I would be choosing the option weekly, just wanted to let you know so that if you might also have the same question [01:02:41] yeah, that sounds about right [01:03:20] kaldari: thats it for now, I would get back to my patch. [01:03:23] and hopefully I'll be more available in the next few weeks [01:03:33] cool, good luck! [01:04:00] kaldari: thanks, happy journey back home ! [13:27:26] any upload wizard dev around? [13:30:40] Just ask. If anyone can answer, they will. [13:45:43] I suspect marktraceur won't be around for another 2-3 hours [14:06:33] just wondered if this https://bugzilla.wikimedia.org/38303 is a clear enough bug report [14:17:43] matanya: was that a filename that you typed in or was that automatically selected? [14:17:59] auto [14:18:28] ok i'll add a note on the bug [14:20:00] thank you [14:20:12] :) thanks for the bug report! [14:21:19] one more to the stock... :D [14:47:52] ^demon: hey do we have release branches branched or tagged on gitified extensions? [14:48:22] or did we not migrate those? [14:49:21] <^demon> brion: No, we didn't do that for extensions. I was just explaining that to RobLa a minute ago. [14:49:38] ok [14:49:44] <^demon> I know Krinkle's been starting to work on the problem, don't know what his current thoughts are though. [14:49:50] then i'll tell this poor guy how to check out a branch, but the branch won't be there ;) [14:50:03] <^demon> Real men use master ;-) [15:11:33] Krinkle, https://bugzilla.mozilla.org/show_bug.cgi?id=738257 [15:12:05] Krinkle, https://wiki.mozilla.org/index.php?title=L10n:Teams:my&action=history [15:12:31] , [15:18:42] arky, it seems that the rich editor is broken... [17:34:48] jeremyb: So I'm starting the packaging notes you gave me [17:35:32] jeremyb: There have been some foreseeable problems, but if you know, what is the purpose of changing to a local mirror? And don't I need to do significant setup to install a local apt mirror? [17:44:48] marktraceur: don't need a local mirror. that was just for that event [17:44:53] Ah K [17:44:59] marktraceur: busy in an event on site now [17:45:10] jeremyb: No worries, I think I've diluted what I need for nowq [17:45:19] Er, distilled [17:45:29] marktraceur: k [18:07:50] marktraceur: Over $3.1M pledged for the OUYA console [18:09:28] * marktraceur sighs [18:09:38] I suppose it was inevitable, but still depressing [18:10:15] It was said somewhere it would come with a dev kit as standard [18:12:15] JeroenDeDauw: TMCW and Will from Mapbox are planning on showing up, looking for mapping-related hackage. [18:14:07] Amgine: cool - I'd definitely be interested in talking to them [18:19:32] JeroenDeDauw: Sweet, I'm currently macbooking in the corner w/ filbertkm , looking for things to help out on / learn about [18:19:53] Also, brion ^: tmcw + Will of Mapbox [18:27:59] Amgine: sure, I'll head over to the main room in a minute [18:28:17] Amgine: I don't know how you look like though - so maybe need to wave :) [18:30:26] I haven't found xyr either. I don't know them, but would like to find them and ask about certain sat weather projections. [18:30:32] (well, how to map to them.) [18:32:29] JeroenDeDauw: [18:32:29] hey, we're over to the left of the microphones if anyone wants to talk maps [19:02:03] * marktraceur is not super-happy about debian packaging right now [19:09:50] jeremyb: OK, I have a package. It's huge, but it appears to be good. [19:10:09] What's the next step in getting the package deployed somewhere? [19:15:19] marktraceur: we should get it moved to git and then you should commit your packaging changes [19:15:31] *nod* [19:15:32] K [19:15:49] marktraceur: and then get it reviewed and then I think you need to get ops to build it [19:15:53] I mean, it's on git, but whatever you'd like. [19:16:06] I'll push it to my master branch [19:16:06] marktraceur: i don't follow? [19:16:14] marktraceur: which repo? [19:16:26] jeremyb: etherpad-lite is already at http://github.com/Pita/etherpad-lite [19:16:34] And I have my fork at /marktraceur/etherpad-lite [19:17:33] ok, great [19:18:10] Damn it. [19:18:17] I didn't git clone, I downloaded a tarball [19:39:10] marktraceur: hi :) Sorry I have been lagging out in my review [19:39:24] still owe you some review about some tests you submitted :-D [19:40:38] hashar, are you referring to tests I submitted? [19:40:44] or someone else? [19:42:53] hashar: It's OK! :) [19:43:04] subbu: Me! [19:43:22] too many context switching already so I am having heavy packet^Wproject losses [19:43:45] hashar: It's fine, I understand that problem all too well [19:44:00] I said three days ago I was going to do something....miraculously, zero progress :P [19:47:35] jeremyb: https://github.com/MarkTraceur/etherpad-lite has my debian changes [19:47:48] Oh, hm, I should probably rebase off the latest Pita/etherpad-lite [19:49:21] will look later [19:49:25] Mmkay [19:49:31] It's now rebased, too, so no problems [19:49:37] k [19:52:24] Also, http://marktraceur.info/shared/packages/etherpad-lite/ [19:52:43] (though less important, since presumably you can build the same thing with debuild -us -uc) [20:50:51] hashar: PHP Notice: Undefined variable: cluster in /home/wikipedia/common/wmf-config/InitialiseSettings.php on line 11011 [20:50:51] Notice: Undefined variable: cluster in /home/wikipedia/common/wmf-config/InitialiseSettings.php on line 11011 [20:51:16] bah [20:52:25] isn't InitialiseSettings.php always required() global space anyway? [20:52:48] oh noo [20:53:23] I knowwww [20:54:27] Reedy: looks like we need: global $realm, $cluster; in wmfLoadInitialiseSettings() function [20:59:07] Doesn't work if it's there... [20:59:24] Reedy: Reedy: https://gerrit.wikimedia.org/r/#/c/15508/ [20:59:49] I am going to sleep right now sorry :/ Cant follow up [21:00:01] that should be fine