[18:54:29] *TrevorParscal battles RoanKattouw on CR [18:54:32] he he [18:54:35] good morning people [18:56:43] *brion waves [18:57:32] hi brion [18:57:48] glad to have you on board for a tid bit of your time [18:58:15] Morning TrevorParscal [18:58:17] boo, how long has this channel been here? [18:58:21] I've only been talking to you on CR today [18:58:23] a while [18:58:26] Nikerabbit: #wikipedia_usability redirects here [18:58:37] Nikerabbit: Logs in topic. [18:58:47] last time I was checked, this was empty [18:58:53] it was created right before Ayreh posted that mailing list post about community vs. centralized development [18:59:35] why was I not invited here? [18:59:55] Wasn't this mentioned on wikitech-l too? [19:00:00] it's just supposed to be where all WMF staff developers can hang out, thus making them accessible to community members, without the noise of lots of IRC bots [19:00:11] This is not meant to be secret... [19:00:18] we could advertise it more [19:00:22] that would be great! [19:00:36] well, it pretty much is secret if *I* wasn't aware of it [19:00:38] everyone is invited. [19:00:39] http://www.mediawiki.org/wiki/Development_process_improvement/Communications_recommendations#IRC_channels [19:00:42] (and support questions noise) [19:00:51] (Support questions aren't noise.) [19:00:57] RoanKattouw: is this better? [19:01:10] Ashlee: They're not noise in the sense of being irrelevant, no [19:01:19] heck, I'm little bit pissed off right now [19:01:20] They are noise in the sense of getting in the way of getting shit done [19:01:26] kaldari: Yeah fine [19:02:09] Nikerabbit: The link above shows all the known IRC channels. [19:02:43] Nikerabbit: I'm sorry you did not recieve notice of this channel, nobody was ever meant to not be invited [19:03:59] TrevorParscal: I'm sure of that, and I'm not blaming anyone [19:04:01] wrt "" - what metric is used to determine trust? [19:05:34] i have no idea. [19:06:11] Ashlee: I see the page first time [19:22:48] RoanKattouw: Any idea which browsers are affected by the problem you mention at http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73232#c9598 ? [19:23:12] Almost all I think [19:23:23] At least Firefox and IE just stop execution [19:23:35] RoanKattouw: I've never encountered an error from that in Firefox [19:23:44] Oh wait [19:23:52] I'm mistaken, you can do it one level deep [19:24:04] That is, you can do foo.bar if foo exists and is an object [19:24:12] But you can't do foo.bar.baz if foo has no bar [19:24:18] ah cool, that would explain it [19:24:36] So please refute my CR comment as appropriate [19:25:19] RoanKattouw: Not often I get to do that :) [19:27:49] RoanKattouw: refutations entered, could you update the status on http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73219 [19:28:43] RoanKattouw: Also http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73232 (which I think you accidently marked as reverted) [19:29:23] OKed both [19:31:33] thanks [19:36:25] kaldari: I'm assuming r73224 is gone also? [19:37:19] no that's still there [19:37:40] there are actually 2 different places where we're accessing meta... [19:38:13] when we pull the banner list it uses $wgCentralDBname to do a db select directly against meta [19:38:32] Oh right you mentioned that that var was still there [19:38:51] I'll get back to those revs once I get to the partial revert [19:39:15] when we pull the banners themselves, however, we're using jsonp, since we still need to keep the message functionality (can't just query the database directly) [19:40:36] Yes [19:40:41] We talked about that earlier [19:44:27] RoanKattouw: All that debugging stuff gets removed later [19:44:57] I just noticed, yeah [19:45:06] (This is why I like rev id references in commit summaries) [19:45:26] RoanKattouw: That was from when I was troubleshooting against the live install after the aborted deploy last week [19:46:17] nothing is every how I expect it in MediaWiki :) [19:46:17] RoanKattrouw: Yeah, those we all done under duress, so no rev references :( [19:46:23] s/every/ever/ [19:46:32] we=were [19:46:43] wfRunHooks seems to be designed to only let callers know if it ran or didn't, right? [19:47:18] flipzagging: No [19:47:50] flipzagging: Every hook function returns true or false. If one hook function returns false, wfRunHooks() aborts immediately, skipping other hook functions, and returns false [19:48:02] That's what I meant [19:48:07] flipzagging: If a hook function returns true, it proceeds to the next one. If all return true, wfRunHooks() returns true [19:48:10] <^demon> In theory, some violate that principle. [19:48:18] <^demon> But mostly true :) [19:48:20] So a return value of false means 'someone wants you to abort' [19:48:21] I mean from the caller's perspective [19:48:22] you can't do [19:48:39] There's a lot of hooks that explicitly document that you can prevent something from happening by returning false from the hook [19:48:41] $something = wfRunHooks('getSomething'); $something->foo(); [19:48:47] (in userCan for instance) [19:48:52] that can't work, since wfRunHooks throws away return values. [19:49:01] flipzagging: That would make zero sense, since more than one function can subscribe to the hook [19:49:14] I assumed it would be the first one that succeeded [19:49:19] If you do want to obtain a value through a hook or have it modified, use a reference [19:49:23] but you have a point, the order of registration wouldn't work [19:49:41] RoanKattouw: way ahead of you, but in this case, the reference is a 'protected' property [19:49:45] therefore I lose [19:49:56] So copy to a local var and back [19:50:05] yeah [19:50:12] still, I seem to be Doing It Wrong. [19:51:04] I can haz pastebin? [19:51:45] not sure if it's relevant but ok [19:52:45] ok, the context is, in api/ApiUpload.php, there is a part of the code where it decides what upload module to use [19:53:00] I am doing it all in an extension, but I need to modify this behavior [19:53:05] so I thought, I know, a hook [19:53:07] http://pastebin.com/J909cBQS [19:53:16] anyway perhaps a dumb idea [19:53:16] RoanKattouw: I'm going to run out for some lunch [19:53:24] Sure [19:53:29] RoanKattouw: want me to pick up anything for you? :) [19:53:31] I'm gonna wrap up and go to bed [19:53:47] kaldari: You mean like breakfast for Wednesday? ;) [19:54:03] I think your original idea of subclassing ApiUpload might be better, but then I need to somehow distinguish that from the 'upload' action. Call it 'uploadToStash' ? that seems strange. [19:54:27] kaldari_eat: I'm almost done with my first pass, see if brion's interested in reviewing the fixes. If not, I will do so tomorrow around 4:30am PDT [19:54:39] cool [19:55:11] flipzagging: And what does the hook do exactly? [19:55:26] RoanKattouw: The main piece I'm worried about is the jsonp, so if you can give detailed comments on anything that's wrong that would be awesome [19:55:31] flipzagging: i have to do a meeting now. i'll be back around later. [19:55:36] looks into the WebRequest, decides if the parameters are such that we should do an UploadFromFileToStash [19:55:43] jorm: me too, ttul [19:56:18] RoanKattouw: then creates a new UploadFromFileToStash, which is just a subclass of UploadFromFile with moar magick [19:57:03] flipzagging: Why is this in an extension again? [19:57:22] RoanKattouw: because it's much harder this way [19:58:00] RoanKattouw: I know you are pro putting it in core, but the entire history of this project has been "fuck off we're not putting this in core"/ [19:58:07] s/\//./ [19:58:49] Fuck that, stashed uploads are useful [19:58:51] fine, I officially give up then [19:58:54] ok [19:58:56] in the meantime [19:59:12] Bryan Tong Minh has been committing a lot of stuff trying to revive UploadByUrl [19:59:27] *RoanKattouw regains sense and rewords that in a more diplomatic way [19:59:48] You're obviously enduring pains by not putting it in core, so it should be in core [19:59:50] except, it's kind of bizarre since he made the "get status of upload" method also an "upload" API call. So there's a lot of "OH I DIDN'T REALLY MEAN TO UPLOAD" stuff [19:59:59] *sigh* [20:00:05] yeah [20:00:24] OK well did anyone ever specifically say that stashing shouldn't be in core? Don't we *have* a different form of stashing in core already? [20:00:29] we do [20:00:38] this is stashing on request [20:01:01] and some other strangeness which makes it possible for the uploading user to find information and view thumbnails of their stashed files. [20:01:14] and then files can be unstashed and committed in the normal way. [20:01:39] *I* think it would be useful in core [20:02:02] anyway it's late, and I have a meeting right now [20:02:16] i will send you an email when I commit this (in branch) (one way or another) [20:15:13] kaldari_eat: Alright, I have now reviewed CentralNotice up to HEAD and I'm calling it a day. brion says he'll be doing his review hour tonight from 7 to 9, and I'll be back around 4:30am, so your followups should be reviewed quickly [20:15:34] mdale: sequencer and P2P are covered in this weeks Signpost btw. [20:15:44] sweet ;) [20:20:49] thedj: technically I am a Kaltura employee working with the foundation not a foundation employee working with kaltura [20:21:18] But nice article blurb, thanks :) [23:14:18] Ryan_Lane: pdhanda@ci:~$ svn co svn+ssh://svn.wikimedia.org/svnroot/mediawiki/trunk/test-server [23:14:18] svn: Network connection closed unexpectedly [23:14:22] any ideas? [23:15:21] interesting [23:15:50] pdhanda: works for me :) [23:16:19] oh crap [23:16:28] *pdhanda smacks forehead [23:19:18] Ryan_Lane: my bad i put the prong key there :P [23:19:26] wrong even [23:19:28] :D [23:27:02] pdhanda, do you have your ssh key in the agent? [23:27:37] ah, you already found it [23:30:19] robla: about? [23:30:28] hi reedy! [23:32:31] by the way, don't forget to update http://eiximenis.wikimedia.org/FeaturesTeam20100928 for tomorrow (ping werdna too) [23:34:58] robla: got half an hour or so, then i'd probably best think about bed!