[10:16:08] #wikimedia [12:30:33] is there some document I could refer that wmf works with much smaller budget than other popular websites? [12:32:54] There's a great slide about this [12:33:05] Let me find it [12:33:46] Nikerabbit: http://wikitech.wikimedia.org/index.php?title=File:Xerox_Parc_Forum_-_How_Wikimedia_is_Scaling_Open_Source_Innovation.pdf&page=4 [12:34:21] That presentation is a year old so the numbers are outdated [12:34:42] Wikimedia is at something more like 400M / $20M / 50 right now [12:35:25] RoanKattouw: thanks, it doesn't matter if it is bit dated [12:36:08] Oh, 73 employees actually [12:36:25] Yeah that presentation was in June 2010 based on the data for the 2009-10 FY [12:36:57] Anyway, the differences are many orders of magnitude so who cares about a factor 2 [12:38:44] I have written an extension for implementing Signup, now this has some public functions which are conflicting with those in SpecialUserLogin, what should I do? [12:39:36] How are they conflicting? Function names are per-class [12:39:58] Unless you're defining global functions or extending the SpecialUserLogin class (and you shouldn't be doing either of those things, I don't think) duplicate names are fine [12:42:11] I am getting this error arse error: syntax error, unexpected T_PUBLIC in /home/simplyth/public_html/www.akshayagarwal.in/mw/extensions/SignupAPI/includes/SpecialUserSignup.php on line 740 [12:44:01] is that due to conflicting names? [12:44:14] <^demon> What does line 740 say? [12:44:18] <^demon> Sounds like a syntax error. [12:44:20] *apergos kinda wishes we had "arse error" as a message... [12:44:41] ^demon: public static function getCreateaccountToken() { [12:45:12] <^demon> Ah, sounds like you might be missing a closing } somewhere. [12:45:23] <^demon> Maybe from the previous function. [12:46:05] i checked but couldn find a missing } [12:46:21] <^demon> Check again ;-) [12:46:31] <^demon> E_PARSE is always from a syntax error. [12:46:33] actually this function is also defined in SpecialUserLogin [12:46:40] as a public function [12:46:48] so, are they conflicting? [12:47:04] <^demon> You might get an E_STRICT for conflicting functions. [12:47:09] <^demon> But it wouldn't give you a parse error. [12:47:18] <^demon> Parse errors are *always* due to a syntax mistake. [12:47:40] ^demon: ok, I ll check again [12:48:14] <^demon> Another way you can confirm is by running "php -l filename.php" from the command line. [12:48:32] <^demon> That will check your file for syntax errors. [12:48:51] *akshayagarwal searches for silly syntax mistakes in 1000 lines if code [12:49:28] <^demon> Well the best place to start is right above the line where PHP complains about the "unexpected T_PUBLIC" [12:49:50] <^demon> And work your way up the file. [12:50:47] ^demon: i ll follow that [12:50:51] <^demon> Good luck :) [13:17:29] ^demon|away : missing } at line no 520, you'r the man! [13:17:42] <^demon|away> Glad you found it :) [16:08:00] hello [16:38:36] has anyone seen alolita ? :) [16:51:35] hashar: I have ^ [18:59:10] anyone free to do a one-line JS review? r90649 [18:59:47] !r 90649 [18:59:47] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90649 [19:00:34] neilk_: OKed [19:00:41] RoanKattouw_away: thanks [21:01:04] i need to do some schema updates on testwiki relating to central notice - is it ok to run update.php for testwiki or is it better to just execute the individual sql files? [21:01:24] <^demon> No, never ever ever run update.php [21:01:34] glad i asked first [21:01:54] <^demon> Run 'php maintenance/sql.php --wiki=testwiki < /path/to/sql/file' [21:02:01] cool thanks [21:02:07] notpeter: here? [21:02:16] <^demon> awjr: Also, schema changes need review first. [21:02:21] <^demon> I assume they've been reviewed :) [21:03:04] yes indeed [21:03:36] <^demon> Then you should be fine. It's only testwiki so it won't hurt too much. [21:03:58] ya - they are apparently schema changes for central notice that are rather old but have never been made live [21:04:16] hexmode: soup? [21:04:16] <^demon> For larger schema changes (especially slow ones for the larger wikis), someone has to do some juggling of the masters for each cluster while the updates run. [21:04:53] notpeter: do yhou know anything about https://bugzilla.wikimedia.org/show_bug.cgi?id=22708 [21:05:54] hexmode: I know no things about this ticket. [21:06:33] notpeter: ok, guess I'll have to email private-l. :{) [21:06:53] <^demon> Or you could just ask mar[k] tomorrow next time he's around. [21:07:13] awjr: testwiki will be fine, but don't go running schema changes on production wikis unless you really, really, know what you're doing [21:07:20] ^demon: but that means WAITING. And I don't want to! [21:07:27] ;) [21:07:27] RoanKattouw_away: i copy [21:08:13] <^demon> RoanKattouw_away: Like adding a new index to revision on enwiki? ;-) [21:08:34] Yeah that [21:08:39] As a rule, table creations are fine [21:08:40] what happens if update.php is run on the cluster? wanton death and destruction? [21:08:52] Anything that touches tables with a non-zero amount of rows is strictly forbidden [21:09:06] And if anyone runs update.php I'll be on the first flight to SFO to slap them in the face [21:09:12] Yeah, death and destruction pretty much [21:09:18] <^demon> Yep. [21:09:27] update.php will attempt to run various expensive updates [21:09:44] <^demon> We should run it against a "testwiki-like" db one day and see if it actually manages to complete without massive implosions. [21:09:47] <^demon> Could be fun [21:09:57] Many schema changes will bring down a large wiki unless executed in a very carefully orchestrated way [21:10:01] Yes, that would be fun [21:10:05] I propose test2wiki, actually [21:10:14] <^demon> Ooh, test2. Nobody cares about that one. [21:10:15] I'm so afraid it'll mess up that I don't want to make testwiki explode [21:10:26] And test2 should be even tinier that test [21:10:50] Hmm, I'm thinking [21:10:57] *hexmode opts to email mark instead of private-l [21:11:00] Maybe we should cripple update.php in 1.17wmf1, just to be sure [21:11:10] <^demon> First line. [21:11:14] <^demon> die( "Don't do this" ); [21:11:26] kaldari was suggesting to rename it to 'whateveryoudodonotexecutethisfile.php' or something [21:11:42] <^demon> People still will. [21:11:46] <^demon> No matter what you name it. [21:11:50] it could look for a config setting that must be manually set [21:11:52] <^demon> Making it die immediately is safer. [21:12:02] and we won't. [21:12:13] im pretty sure naming it that would actually make me want to execute it even more [21:12:23] if we add die to it, the next time we switch to a new release we'll forget about it [21:14:10] <^demon> No we won't :) [21:15:08] remember how we're going to deploy from trunk regularly? :-P (some daaaaay over the rainbow :-P) [21:15:20] We can still have patches [21:15:22] We'll need to [21:15:27] A var might be nicer [21:16:08] I'd rather it be something in localsettings or whatever, then we can turn it off "properly" [21:16:28] Yeah [21:16:34] I'll file a bug [21:16:38] cool [21:16:46] Maybe I'll do this on the train some time or something [21:18:01] <^demon> I already livehacked it in 1.17wmf1 :) [21:18:06] <^demon> Maybe a real solution would be cool. [21:18:23] yes it would :-P [21:18:32] say, log that live hack wouldja? [21:18:37] <^demon> It's in svn [21:19:33] well there's svn and there's deploying it [21:20:00] unles you're intending to leave it for the next sync-common-all as a sleeper commit :-P [21:20:23] thanks [21:20:25] <^demon> It's a maintenance script, it doesn't need sync'ing [21:20:53] no? [21:20:54] I just filed bug 29558 [21:21:02] No, it doesn't need syncing [21:21:08] They're only ever run from the command line [21:21:13] On NFS boxes [21:21:15] I run a pile of maintenance scripts, and they all need to be locally synced [21:21:28] Yeah because you're actually crazy enough to run them on a non-NFS host [21:21:31] *and* I don't have home mounted on those boxes [21:21:33] Nothing and nobody else does that [21:21:36] ( \o/ ) [21:21:46] Normal people run their maintenance scripts on fenari or hume :P [21:21:50] I am so glad not to have home as a dependency on those [21:22:04] normal people don't create 350 gb xml dumps :-P [21:22:16] That's entirely true [21:22:19] Your case is special [21:22:24] but everybody wants them [21:22:27] :-D [21:22:35] People who create 350GB dumps also don't run update.php [21:22:37] Syncing couldn't hurt I guess [21:22:37] <^demon> s/Your case is/You're/ [21:22:39] *RoanKattouw does it [21:22:51] I'm special, awww :-D [21:23:19] well if I ran it it wouldn't do anything now. right? :-D [21:23:28] I am not going to test it [21:23:51] <^demon> Well if you tried, you'd have the 5 second countdown to abort :p [21:24:02] reminds me too much of the last 5 times that someone has said "oh, yeah, you can't delete the main page (enwiki) any more, that's been disabled." "oh? click... er... oooops..." [21:24:24] I'd rather not be one of those 5 times :-D [21:24:24] Don't you like need the bigdelete right there? [21:24:38] it finally got fixed [21:24:40] <^demon> Well that, and the live-hack in CommonSettings I believe. [21:24:41] plus the sandbox [21:24:45] plus etc. [21:25:25] Fixed how? As in impossible to delete? [21:25:55] as in configured so admins can't just go around deleting that stuff now [21:26:02] even by accident [21:27:06] <^demon> There's a hack in CommonSettings or something like that to prevent it. [21:28:09] <^demon> Look for wfNoDeleteMainPage() [21:29:21] function wfNoDeleteMainPage( &$title, &$user, $action, &$result ) [21:29:22] yup [21:29:26] hah relaly [21:30:02] $result = array( 'cant-delete-main-page' ); [21:30:02] return false; [21:30:05] yup [21:30:54] // Only use this shitty hack for enwiki. Thanks. [21:30:57] man, 2008? really? [21:30:58] heh [21:31:01] how time fllies... [21:33:14] <^demon> Yep, it has been awhile since that happened :p [23:15:16] Ryan_Lane: I'm at http://opensourcebridge.org/sessions/635 [23:15:21] "Inviting Contributors to Open Source Webdev through Virtualization" [23:15:25] any question you want me to ask? [23:15:34] hmm [23:16:05] I've already said "we are doing something like this, talk to Ryan Lane espec if you have done something like this with OpenStack" :) [23:16:13] would any of the devs also be interested in doing ops inside of a virt environment as well [23:16:31] or do they basically just want an environment set up by ops that they can do dev in? [23:16:47] the people in this talk seem more interested in the latter [23:17:00] Ryan_Lane: but it seems like you should chat with Les Orchard [23:17:14] who's that? [23:17:19] Ryan_Lane: the presenter :) [23:17:28] ah [23:17:29] heh [23:17:31] <^demon|away> Ryan_Lane: When are you going to start handing out vms? [23:17:32] <^demon|away> :) [23:17:54] we're talking about vagrant, which I had not heard of before [23:17:58] lemme get back you you guys :) [23:18:11] Ryan_Lane: ok. Just wanted to let you know about the discussion [23:18:21] if you had 1 burning question or "please help me with foo" I would pass it along [23:18:37] vagrant is a virt builder [23:18:44] it's not the route I'd like to go [23:19:17] it's virtualbox based, and is for individual systems [23:19:39] I'm looking to set up virtualized clusters [23:20:17] well, soon, if anyone there wants to do ops or help with mediawiki development, they can help us in our virt environment [23:20:20] Ryan_Lane: I relayed that as "another approach to consider" :) [23:20:26] heh [23:20:40] well, it's interesting, but is the opposite of the approach we are taking [23:21:11] ok. gotta go :) [23:21:22] sumanah: thanks for the info though [23:21:32] maybe I'll talk to the presenter at some point [23:21:45] bye Ryan_Lane [23:21:51] thanks for mentioning it :) [23:26:02] Sumanah: on second thought, I can see a good use for this [23:26:25] Damn she is gone [23:28:02] alolita1: ping [23:28:47] ugh. i have to retool the StructuredProfile document. [23:28:56] it's just not going where I think it needs to go now.