[00:34:03] maplebed: I wish the test swift cluster wasn't so slow :/ [00:34:27] AaronSchulz: slow in what way? [00:34:42] particularly write ops [00:35:11] the pmtpa cluster is significantly faster than the eqiad cluster. [00:35:15] (if that helps) [00:35:23] are you trying to do tests with lots of data? [00:35:57] just playing around uploading and viewing files [00:36:01] on a MW test install [00:36:10] I suppose what I'm most curious about - what are the tests you're doing that the speed is visible? [00:36:29] hm. [00:36:36] though it could be a network issue [00:36:38] I haven't tried MW writes; only the thumbnail 404s. [00:36:48] Try against the pmtpa cluster? [00:37:08] it's that for production? :) [00:37:09] it's at msfe-pmtpa-test.wikimedia.org:8080 [00:37:14] nope. [00:37:22] that what is copper for? [00:37:32] but it's closer, being made up of 6 machines (3 proxies, 3 storage) rather than just 3 sharing duties. [00:38:06] copper I put up for functional testing for you. the pmtpa cluster was for performance testing so I wouldn't impact your tests. [00:38:40] is the pmtpa at all stable? [00:39:14] "stable" [00:39:15] yeah. [00:39:18] should be. [00:39:21] it doesn't do any sharding [00:39:47] and there's currently ~16 million objects in the commons bucket [00:39:55] (commons-thumb bucket) [00:40:08] so it will be a little slower than other containers [00:40:23] but it shouldn't be noticable unless you're doing sustained throughput testing. [00:40:42] any everything should be faster than the eqiad cluster. in theory. ;) [00:40:44] deletes are fast though [00:41:03] *AaronSchulz will be using his own bucket [00:41:09] rock on. [00:41:23] *buckets :D [00:45:08] *AaronSchulz tests [00:49:43] maplebed: wow, delete/restore is faster now [00:49:51] \o/ [01:28:41] *AaronSchulz debugs copy_object_to [01:43:06] freezes up apache 1/2 the time [03:14:37] anyone available for support? [03:24:43] !ask [03:24:43] --elephant-- I don't know anything about "ask". [03:24:47] bah [16:18:42] RoanKattouw - I'm working on clicktracking for the edit links as per Dario's request, and I'm curious about whether it would be better to track users from click to save attempt to complete using cookies instead of the get/post passing I'm doing for AFTv5 now. [16:19:14] I was hoping to use Vector as a crib sheet, but I don't see any use of the save hooks in there [16:20:01] I guess you could use cookies [16:20:12] But ... well it's tricky [16:20:35] You'd have to drop the cookie after the submission, at least, to make sure any subsequent edits aren't counted wrongly [16:20:39] And even then [16:21:28] ah, good poin [16:21:29] I would prefer just using query string params for this [16:21:30] *t [16:21:48] cool, just checking that i hadn't missed something obvious [16:21:56] There are so many edge cases that cookies allow for, at least with query params you're pretty sure those will never happen unless the user copypastes the URL from the address bar [16:22:15] yeah [16:22:22] Basically the important thing here is that you're not tempted to call clicktracking from a click or submit hook [16:22:26] in JS that is [16:22:56] i'm not sure what you mean [16:23:17] I mean $('#submitForm').click( function() { $.trackAction( ... ); } ); [16:23:22] Or $('form').submit( ... ) [16:23:41] Someone did that once, it slipped through CR and ran on the cluster for quite a while [16:24:10] I was quite surprised that that had even produced actual logged events, apparently the behavior is browser-dependent [16:24:23] huh [16:24:26] I can at least tell you that it doesn't work in Firefox, AJAX requests get canceled as soon as Firefox starts navigating to another page [16:24:33] What happens is this [16:24:37] ah, i see [16:25:01] User clicks button or link -- your handler runs -- AJAX request to api.php starts -- browser prepares to navigate away -- AJAX req canceled -- browser goes to next page [16:25:27] Apparently there are browsers that allow the AJAX req to run for long enough to actually make it to our servers. Firefox nips it in the bud [16:25:47] So this is why we do the URL mangling stuff for links [16:25:57] i think i have all the navigation away from aftv5 using tracking urls, but i'll double-check [16:26:01] Because $('a.foo').click( function() { $.trackAction( ... ); } ); has this exact bug [16:26:03] I think so, yeah [16:26:55] thanks for the heads-up and the explanation; i'll keep an eye on that going forward [16:27:04] Sure [16:27:37] I've been keeping an eye out for this pattern in review, so I don't think there's any instances in AFTv5 and I'd be embarrassed if you found one [16:49:10] is there a nice way to find users that made the biggest contribution to a specified namespace? [16:49:39] I think that might be doable via a SQL query, but am not sure about that... [19:02:36] surrur [19:02:40] hi all [19:02:50] starting our features team meeting nw [19:02:52] now [19:02:52] good morning [19:02:59] hi gabriel! [19:03:04] good night! [19:03:25] ;) [19:03:40] our meeting agenda [19:03:58] Meeting??Agenda:1. Brief (2-3 minutes) status update by each??team??for project teams listed below:a. Editing tools: Visual Editor [Trevor], Parser [Gabriel] [19:04:11] I see the format's changed [19:04:11] Trevor - you want to start [19:04:18] Back to person-based, in the Etherpad at least [19:04:30] RoanKattouw: not that i know of - it is the same as last week [19:04:37] err, it doesn't seem to be. [19:04:39] tparscal: you around? [19:04:48] i figured there was a reason for the change... [19:05:06] The Etherpad format changed [19:05:10] Apparently the meeting format has not [19:05:16] raindrift: can you please sync up the format - i understand that guillaume changed it somewhat [19:05:25] for wikifying the content [19:05:30] Trevor's on his way [19:05:45] ok - gwicke: update on parser then :-) [19:05:48] welcome to sf [19:05:57] trevor should be ready soon though [19:06:26] ok ; should we get back to the visual editor then [19:06:27] anyway [19:06:31] alolita: the formatting is the same, but there's no project names, only people. do you want me to put the project names back? [19:06:36] parser update by gwicke [19:06:41] I worked on getting template expansions working [19:06:44] raindrift: please do [19:06:57] mostly modified the token stream transform framework to support that [19:07:03] hi TrevorParscal [19:07:17] so that the actual template expansion extension remains small [19:07:17] hi, sorry for being late [19:07:25] np [19:08:01] I hope to get template expansion working somewhat this week [19:08:19] great [19:08:24] and figure out a few more details with Trevor [19:08:28] i need to set some more time aside for that [19:08:31] yup [19:08:35] that's it from me really [19:08:50] TrevorParscal: you should indeed; [19:09:00] gwicke: thanks [19:09:02] yes, no worries [19:09:25] TrevorParscal: welcome back from vacation; any updates on the VED - did you have a chance to dig through the feedback [19:09:37] i saw a ton of bugs [19:09:40] got through my email [19:09:50] through email not bugzilla [19:09:53] Yeah there was a deluge of VE bugs shortly after you left [19:09:58] VED? [19:10:03] VisualEditor? [19:10:11] yup - VED = VisualEDitor :-) [19:10:31] this week I am working on assessing the next steps for visual editor [19:10:46] I'm looking at some of the larger problems we postponed to hit our release date [19:11:10] i also have to prepare for LCA a bit and of course make the best of my time with gwicke [19:11:14] that's about it for me [19:11:27] sounds like a full plate - thanks [19:11:41] b. Editor Retention: Feedback Dashboard [Brandon, Benny, RobM], AFT v5 [Howie, Dario] [19:11:53] Feedback Dashboard update: Benny, RobM [19:12:06] rmoen: update [19:12:35] bsitu: ? [19:12:41] trying to push to prototype today: unanswered filter, added concurrency api [19:12:46] This week we are integrating feedback dashboard responses with concurrency api [19:13:07] As well, placed moodbar feedback into user contrib logs [19:13:15] unasnwered filter, concurrancy, contribution logs, and leaderboard. [19:13:21] bsitu: did you have a chance to sync up with ian on concurrency [19:13:59] Ahh yes we will be also going live with the Top Responders (Leaderboard) on Feedback Dashboard [19:14:01] I checked in with ian late yesterday, we will merge the code to trunk [19:14:10] rmoen, bsitu: so the plan is for jorm and hfung to test / verify today [19:14:18] bsitu: good [19:14:27] in the copious spare time we have available. [19:14:35] I also have some code review feedback for moodbar [19:14:39] will work on those as well [19:14:44] jorm: we deploy tomorrow so need you to test :-) [19:14:54] bsitu: ok [19:15:25] rmoen: top responders data has been verified by dartar [19:15:51] hey alolita, are we changing the format of the weekly report? [19:15:56] DarTar: are you planning to take a look and verify [19:16:21] sure, rmoen do you want to come and find me this afternoon? [19:16:27] DarTar: no - it should be the same as last week [19:16:41] DarTar: thanks [19:16:45] erm, I see it's now organized by person not by project [19:16:52] alolita: RoanKattouw: The format is my cause. When the new pad was created it copied from last week, which only contained "Saved to wiki page" between and , so there was nothing. I didn't know of any blank template so I created one. Didn't concisely choose for this format, just what I thought of. [19:16:57] alolita: if we're going to deploy, we'll need someone (who's not me) to do some code review. [19:17:17] Krinkle: look back in the history [19:17:22] DarTar: I'm changing it back... [19:17:28] Krinkle: i see ; that threw off everyone :-) [19:17:35] raindrift: thanks [19:17:45] personally, i think that "per person" makes more sense than "per project" but that's me. [19:17:48] raindrift: We're gonna deploy what now? [19:17:56] I'm building the new template at http://etherpad.wikimedia.org/FeaturesTeam-Preload and will fix up this document once it's done. [19:18:18] alolita: RoanKattouw: Perhaps it's worth considering switching to person-based though. Since we have project pages with /status for those that want to know about a status. For the team meeting it may be useful to have everything per person, so that we can work and help more as a team (i.e. if I want to know what Roan is working on I don't have to scroll back and forth. If I want to know RL status I can check mw:RL/status [19:18:19] RoanKattouw: changes to Feedback Dashboard. sorry for the lack of context. :) [19:18:26] jorm: I agree [19:18:31] jorm, I second that but aggregating notes by project at the end of the month will become harder [19:18:40] RoanKattouw: we need your eyeballs for cr on concurrency code before deployment [19:18:50] maybe two sections: per person, and then project notes. [19:18:51] Trunk state is reviewed now [19:18:58] I didn't see any concurrency code in SVN yet [19:19:03] jorm: that doesn't really work if half of our team is not attending in this meeting [19:19:07] jorm: guillom would not agree with you [19:19:08] I remember per-person in face-to-face meeting as well, but anyway - sorry for interrupting, reading back now, was AFK. [19:19:17] RoanKattouw: it's in a branch, since the caching layer wasn't done. i'll check it into trunk today. [19:19:20] yeah, I've been filling out a "my stuff that is not covered elsewhere" section for a few weeks [19:19:38] But if this code is not in SVN 24 hours before deployment, you shouldn't take the deployment for granted. Basically, if I find anything wrong with it that takes >1hr to fix, you're screwed [19:19:58] RoanKattouw: I realize. that's why i'm letting alolita know. :) [19:20:06] RoanKattouw: i agree; [19:20:14] raindrift: what are you saying though :-) [19:20:56] hfung: aft status [19:20:58] alolita: I'm saying we're just finishing up this code now and checking it in today. whether it gets reviewed in time for deployment is not necessarily something i can control. [19:22:00] raindrift: yup; checkin the code and RoanKattouw will need to review and clear before any of it is deployed [19:22:01] for AFT [19:22:04] *guillom scrolls back. [19:22:16] guillom: hi [19:22:22] we're planning on deploying a more prominent feedback link this Wednesday [19:22:22] howief: go ahead [19:22:29] cool [19:22:29] Here is a version on prototype: [19:22:31] http://prototype.wikimedia.org/release-en/Test_table?debug=true&aftv5_show_link=true&aftv5_link=D [19:22:57] alolita: sounds good. If Roan will be reviewing, I'll coordinate with him directly. [19:23:06] we're also planning on click-tracking the edit tab so that we can establish a baseline to study potential cannibalization later [19:23:15] raindrift: please do - thanks! [19:23:21] howie: just mailed you about the behavior of that side thinger tab thinger. [19:23:30] ok [19:23:35] got it [19:23:57] That's it for AFT [19:24:02] this release is small from a technical standpoint [19:24:03] So, about this etherpad??? someone just undid the changes I was making to the template. Before I continue, can we decide on a format for it? [19:24:09] but is likely to cause some controversy within the community [19:24:26] raindrift: I'm flying to Australia this week, though. Going to the airport on Thursday morning my time, so I will not be available in a meaningful way after let's say 1pm or 2pm PST on Wednesday [19:24:28] howief: thanks - but the impact and feedback will be big :-) [19:24:39] we certainly hope so! [19:24:51] RoanKattouw: I'm out Wednesday anyway. This code should be ready for review today. [19:25:03] raindrift, RoanKattouw: today is our day [19:25:08] for cr [19:25:16] Yeah [19:25:18] raindrift: I'm holding off until someone makes a decision on the format, I have a preference for per-person but I can adjust my notes either way [19:25:30] You have a few hours then, I'm not gonna stay up very late [19:25:40] I'm not touching it right noe, especially if we're having edit wars about it. [19:26:08] raindrift: i am ok with a per person format (which is what we had started with) but we are interested in helping guillom with his monthly project reporting also [19:26:17] guillom: any comments? on this format [19:26:36] alolita: yeah we expect some big impact and we may find out that that fixed positioned trigger is also more effective to get readers to edit than the edit tab [19:26:44] If people actually update the /status subpages regularly, then I don't mind if the weekly status meeting focuses on people [19:27:09] that's a big If? [19:27:11] Basically, if the information is available for me to write the monthly report, and easy to find and use, I don't have to nag people [19:27:16] guillom: thats the issue - some folks update the subpages regularly and some don't [19:27:51] DarTar: yup agreed [19:27:53] Nikerabbit, very big if, indeed. Few people update the status pages, which isn't a big issue if they provide project updates during the features team meetings [19:28:06] i was unaware of these pages. where do i find them? [19:28:21] on mediawiki.org [19:28:24] https://www.mediawiki.org/wiki/Wikimedia_Features_engineering [19:28:45] guillom has done an excellent job of organizing the info [19:28:48] And I think raindrift just made me die a little :) [19:28:56] :-) [19:29:04] I'm working on a short howto guide for first-timers. [19:29:05] guillom you should also specify that markup is used to aggregate from these status pages into the engineering report, if people manually edit the pages this will break the transclusion [19:29:18] right? [19:29:28] DarTar: i think thats what we're seeing happen on the etherpad for the last 2 weeks [19:29:41] DarTar, yes and no, I can fix it if it's borked. [19:29:50] guillom: awesome! I'll totally update these. thanks! [19:30:08] so let's discuss the format of the etherpad after the team mtg (here on irc) [19:30:25] so are we saying that we're moving to the status pages for project-based reporting and the weekly etherpad will be person-based? That would makes sense to me [19:30:31] I'm fine with that [19:30:37] that works for me [19:30:52] And if we do that, I'll try to encourage more people to update the project pages [19:30:56] and guillom and i will start nagging everyone who isnt updating the status pages [19:31:19] perhaps we could update the project status pages as part of prep for this meeting. [19:31:22] Sounds good to me. I'll finish that howto guide this week then [19:31:35] project documentation is just as important as people updates in the team meeting :-) [19:31:56] raindrift: that would be excellent [19:32:03] so let's move on [19:32:07] I think that keeping status pages up-to-date with deployment info and dates is particular critical if we want to point editors to changes that affect them (and affect the data we collect) [19:32:13] if we had page somewhere that aggregated the most recent status update from each project, we could look at it during this meeting also. that'd be sweet. [19:32:37] raindrift, that's what the page I linked above does, actually. It's automagic. [19:32:40] we would need guillom to do some magic on mw.org [19:32:54] c. I18n: Narayam, WebFonts, Translate [Siebrand, Amir, Santhosh, Niklas, Gerard] [19:32:54] (there's some dark template voodoo involved, but it's manageable) [19:32:57] oh, right. it totally does. awesome. [19:33:02] isn't that what the monthly engineering report page does (aggregate) [19:33:07] hallo [19:33:10] ping [19:33:31] We had quite a big deployment yesterday [19:33:37] guillom, raindrift, krinkle: you're all drafted to work on the documentation/templating/magic [19:33:38] Krinkle, yes, the monthly report aggregates statuses by date; the Features and Platform hubs aggregate by most recent [19:33:55] Nikerabbit: go ahead [19:33:56] guillom: ah, nice :) [19:34:05] Mostly Translate extension, but also other things like WebFonts and Narayam had preference migration [19:34:26] And we just ended sixth sprint today [19:34:33] i finished the "translation workflow states" - marking that translation is in-progress, proofread, deployed etc. Now the states themselves are translatable to other languages. [19:34:33] Thank you so much for fixing that editintro bug btw, Nikerabbit :) [19:34:56] Nikerabbit: yup [19:35:31] Ah, edit intro bug is fixed ? Great! I see that also fixed the editintro problem that was on Meta-Wiki (newarticletext was gone) [19:35:36] aharoni: cool - can this be demo'ed [19:35:59] Krinkle yes, it was an issue with the Translate extension. [19:36:17] And we are using translatewiki.net to find out what code still uses legacy JavaScript stuff, thanks to Krinkle we also have logging of JavaScript errors [19:36:30] aharoni: any other updates; santhosh's webfonts preview ? [19:36:38] our next sprint is mostly about testing, testing, testing - QUnit and PHPunit tests for WebFonts, and documentation for Narayam and the Translate extension [19:36:49] Yep, we're logging client-side exceptions now, not perfect but never been done before and has already shown lots of fruit :) [19:36:49] alolita: that is live too: http://www.mediawiki.org/wiki/Special:WebFonts [19:36:57] Santhosh made a Special page for previewing web fonts. [19:37:13] it's not linked from anywhere yet, so it's small impact for now [19:37:18] aharoni: yup - very useful to do a testing sprint [19:37:34] it has (potentially) a pangram ("the quick brown fox jumps over the lazy dog") in every language. [19:37:59] it shows the available fonts and allows users to download the font and install it properly on the system. [19:38:05] nikerabbit: thanks for the link; i have been checking it out; good for the features team to check it out and give feedback - esp ui related [19:38:22] And Santhosh has been working on supporting GENDER and PLURAL in JavaScript, GRAMMAR is next [19:38:22] jorm, tparscal, krinkle - ui feedback needed [19:38:36] nikerabbit: yup [19:38:38] on what? [19:38:49] on the preview feature for webfonts [19:38:54] Nikerabbit: No webfonts for Sinhala? [19:38:54] jorm, http://www.mediawiki.org/wiki/Special:WebFonts [19:39:02] jorm: TrevorParscal: http://www.mediawiki.org/w/index.php?title=Special:WebFonts [19:39:12] Nikerabbit: I thought I saw test cases for GRAMMAR passing already? [19:39:12] is this user facing? [19:39:16] yup [19:39:23] jorm: yes it will be [19:39:47] RoanKattouw: it certainly does not contain all the language specific logic, I don't know if it contains the forms from the globals [19:39:57] well. it doesn't seem to work for me at all. [19:39:57] Hmm, right [19:40:05] RoanKattouw: no support for sinhala right now [19:40:19] until we have the fonts tested and then integrated after community feedback [19:40:21] alolita, jorm, it is already user-facing, for example in Hindi: http://hi.wikipedia.org/wiki/Special:WebFonts [19:40:55] jorm: try choosing language like ta, or, ml [19:40:59] aharoni: yup [19:41:06] aharoni: anything else we did last week? [19:41:22] ta, ml don't have this support yet [19:41:38] that actually gives me a download link that works, but the font doesn't appear to change much. [19:41:38] Nikerabbit / aharoni : Preview feature is cool :-). Perhaps we'll become the universal source of quick fox sentences. [19:41:52] :-) [19:41:53] the text box is pretty large. [19:42:09] i think on font change we should probably try to pre-populate with some text in that native language. [19:42:37] i get that switching the font won't change the ascii codes i have set in there already but for some reason i thought it would be all "webdings". [19:42:55] "Download" should be "Download this font". [19:43:07] can we do the review sometime else and not in this meeting? Half of our team is not here currently [19:43:20] We're also taking up precious time [19:43:21] jorm: can you please send a consolidated note later today to the i18n team [19:43:29] so this week [19:43:32] on your ui review (thanks!) [19:43:32] or two weeks [19:43:36] this week [19:43:50] documentation, unit tests (PHP and JS) and code review [19:44:08] nikerabbit, aharoni: anything else [19:44:12] yes [19:44:35] I'm writing tutorials for Translate, like https://www.mediawiki.org/wiki/Help:Extension:Translate/Page_translation_example and Narayam is getting user documentation [19:44:38] krinkle, hashar: please help the i18n team on testing; we are planning to integrate [19:44:57] nikerabbit: awesome [19:45:01] we are really going to dive deep into the unit testin world [19:45:18] nikerabbit: ++1 [19:45:35] alolita: Yep, I'm on this with hashar. We plan to make the final switch from my initial qunit-hack from Berlin to Special:JavaScriptTest from JSTesting branch this week [19:45:38] krinkle: we need your help on this [19:45:48] which will enable things like this automatically [19:45:54] krinkle: awesome [19:46:02] we talked today in our meetings that we have had to postpone some stories mlutiple times because we are not getting the required help from people outside of team [19:46:17] hopefully this doesn't happen with unit testing [19:46:20] nikerabbit: yup especially on the ui side of things [19:46:20] Stuff like what? [19:46:29] it is already fairly stable in trunk, so i18n should not have to wait for this deployment. That's only required in order to run it on the live swarm at integration.mw.org but the test suite runs perfectly fine locally in everyone's browser and local dev wiki. [19:47:09] stuff like how to do feedback links and Narayam/WebFonts ui redesign [19:47:14] RoanKattouw: quite a few dependencies on jorm, krinkle, neilk on integrating features like feedback, ui design, testing into the i18n world [19:47:42] Right [19:47:42] nikerabbit: working on getting alternatives; so will keep the team posted [19:48:04] alolita: yes please (and postponing here means the next sprint = 2 weeks) [19:48:14] nikerabbit: yup [19:48:30] that's all I have to say [19:48:43] nikerabbit: thanks for a thorough update :-) [19:48:52] trying to be more concise next time [19:49:12] :-) d. Multimedia: Upload Wizard, TMH [Ian] [19:49:25] raindrift: upload wizard updates [19:49:31] we fixed a bug. [19:49:58] a small one with high impact [19:50:00] roan deployed it. there's been a fair bit of code reorganization, but i haven't been working on that part myself. [19:50:15] totally. the custom license feature was broken. [19:50:34] RoanKattouw: thanks [19:50:57] for TMH, we're trying to put together a test deployment on labs. it's more complicated than we initially suspected, since labs lacks a few things for making a truly commons-like environment. [19:51:24] The aim is to get it all there, but that takes time [19:51:37] I think scalers are pretty well puppetized though [19:51:43] (I'm assuming that's what you need) [19:51:46] next step is to finish reviewing what we actually need to do meaningful testing. we may be able to do it with what's there already. [19:51:56] raindrift: dependency on ops ; i have talked with ct about this ; he needs to assign a resource who can work with us to define the basic subset of the environment needed for tmh [19:52:06] mostly i'm concerned that we'll run into cache-related bugs. [19:52:12] Right [19:52:17] This shouldn't be too hard [19:52:24] Spin up 2 scaler instances and 2 appserver instances [19:52:35] And a memc instance, I guess [19:52:47] All of this stuff is puppetized, so you're lucky [19:52:58] it sounded like there was more to it when ryan lane and i discussed it last week. [19:53:00] The upload Squids aren't in puppet yet, so recreating those in labs is very much nontrivial [19:53:07] for the encoding backend also a setup with a shared files store is needed [19:53:08] I'll defer to Ryan then [19:53:09] that's the main thing, yeah. [19:53:16] RoanKattouw: but puppet needs to be configured on labs (from what i understand) [19:53:17] Right, shared file storage [19:53:20] NFS [19:53:31] also, how are you gonna configure mediawiki? [19:53:46] I guess deployment-prep already has a commons set-up [19:53:51] Steal the deployment-prep thing? [19:53:56] Right [19:53:57] raindrift, try to gently prod brion into helping you with TMH. he's interested in seeing it happen and may be willing to put some effort toward that. [19:54:09] Eloquence: will do. thanks! [19:54:23] Maybe we could extend the deployment-prep project with multiple appservers if it doesn't have them already, and multiple scalers, and NFS for file storage [19:54:25] I'd integrate in with deployment-prep, if you can [19:54:30] it's a good idea [19:54:35] Yeah [19:54:41] Eventually, deployment-prep will become the cluster clone I guess [19:54:42] deployment-prep should be as close to production as possible [19:54:52] I *really* need to get that other node in [19:54:55] ryan_lane: agreed [19:55:08] ryan_lane: do you know when :-) [19:55:26] I'm planning on getting a new node in today [19:55:31] which should help with performance [19:55:34] err [19:55:36] not today [19:55:37] this week [19:55:49] ryan_lane: that sounds more doable :-) (this week) [19:56:00] yeah, especially since I'm in a class today [19:56:17] yup; when are you back in the office [19:56:49] ryan_lane: this week ? [19:56:58] tomorrow [19:57:24] ryan_lane: ok cool; will sync up with you then [19:57:34] so let's move to resource loader [19:57:45] RoanKattouw, Krinkle: when? where are we? [19:58:07] RoanKattouw: ? [19:58:09] OK so [19:58:18] We reinventarized where we're at with RL2 [19:58:29] and updated the wiki page with the TODO list and stuff [19:58:35] what he says [19:58:38] link? [19:58:39]