[00:02] <StevenK> wgrant: Are you for reviewing https://code.launchpad.net/~stevenk/launchpad/bugs-information_type-ui-portlet/+merge/103193 ?
[00:03] <wgrant> StevenK: Probably not right now, (see -ops)
[01:32] <StevenK> wallyworld_: Since wgrant is distracted by *redacted*, can you review my branch?
[01:33] <wallyworld_> StevenK: ok, just give me a few minutes before i look. i've found a flaw in our person vocab i'm in the middle of fixing
[01:51] <StevenK> wallyworld_: Still distracted?
[01:51] <wallyworld_> StevenK: just writing up a mp, almost done'
[01:51] <StevenK> Should I prod lifeless so I can have three people who are too busy to review my branch? :-P
[01:51] <wallyworld_> it's complicated so i wan tto do it before i forget what i need to say
[02:03] <bigjools> wallyworld_: at your age, it's easy to forget I suppose
[02:04] <wallyworld_> bigjools: fuck off
[02:04] <bigjools> exactly my predicted response :)
[02:04] <wallyworld_> StevenK: looking now
[02:09] <wallyworld_> StevenK: test_proprietary_hidden - i don't think the test is sufficient. proprietary should only be visible if the bug is targetted to a commercial project right? and the test doesn't do that so i think it will succeed even without the feature flag
[02:10] <StevenK> wallyworld_: We don't currently limit it like that.
[02:11] <wallyworld_> we are supposed to i think. it's limited like that on the +sharing page
[02:12] <StevenK> wallyworld_: For the moment, we hide it in the UI everywhere via the feature flag
[02:12] <StevenK> I'm just making sure it isn't leaking into the JS
[02:13] <wallyworld_> ok. so long as we don't accidentally toggle the flag and have proprietary exposed when it shouldn't be
[02:14] <StevenK> wallyworld_: I know PROPRIETARY needs more work.
[02:14] <wallyworld_> yeah. hopefully between the 5 of us we won't do something dumb by mistake
[02:15] <wallyworld_> it wouldn't be much work though to add the extra check
[02:16] <StevenK> wallyworld_: So it also dealt with correctly on Bug:+secrecy and a few other places
[02:16] <StevenK> It needs careful thought and planning
[02:17] <StevenK> So I don't want to go off and just do this, I'd like the five of us to discuss how we handle that and do it properly
[02:17] <StevenK> (In a new branch
[02:17] <StevenK> )
[02:17] <wallyworld_> so we must enable disclosure.proprietary_information_type.disabled on prod before landing this then
[02:19] <StevenK> It doesn't matter, it won't get hit because show_information_type_in_ui is off
[02:20] <wallyworld_> it would be good to turn it on though as a safety measure
[02:21] <StevenK> Right
[02:21] <wallyworld_> just to ensure it's there when we do toggle the show in ui flag
[02:21] <StevenK> I wasn't planning on setting anything on prod yet
[02:21] <StevenK> And have all 3 flags set on qas on Thursdasy
[02:22] <wallyworld_> ok
[02:22] <wallyworld_> StevenK:  if (privacy_link && LP.cache.show_information_type_in_ui) {..... do you think a nested if() would be better?
[02:22] <wallyworld_> if( privacy_link) { if(show_in_ui) ... else ....  }
[02:24] <StevenK> I can, I didn't think it was worth it
[02:24] <lifeless> -> dentist
[02:25] <wallyworld_> StevenK:  i think it's cleaner. i'll leave it up to you
[02:25] <StevenK> wallyworld_: I was trying to avoid indenting the inner block another level so the diff isn't massive
[02:25] <StevenK> Since the current JS code there is about 150 lines
[02:25] <wallyworld_> figured as much :-) i don't mind an extra few lines in the diff if the code is cleaner
[02:26] <StevenK> wallyworld_: I'd personally prefer a smaller diff :-)
[02:27] <wallyworld_> why?
[02:27] <wallyworld_> surely final code clarity is most important?
[02:27] <wallyworld_> i couldn't really care less about the diff size
[02:28] <StevenK> wallyworld_: TBH, I'd rather not touch that 150 line massive block at all -- it's untested, and I can hopefully delete it in two weeks or so.
[02:28] <wallyworld_> ok
[02:28] <wallyworld_> StevenK: 120	+ title: "Change Information Type"    should be "Change information type"? not sure
[02:30] <StevenK> Hmm
[02:30] <StevenK> wallyworld_: Which do you prefer?
[02:30] <wallyworld_> whatever the coding standards say
[02:31] <StevenK> I just fixed Bug:+secrecy to say Change information type
[02:31] <wallyworld_> i think it's "Change info type"
[02:31] <StevenK> So let me fix this too
[02:31] <wallyworld_> cool.
[02:32] <wallyworld_> StevenK: also, information_type_edit.on("save", function(e) {...}) -- the guts of the function should be broken out into a separate method which can be unit tested
[02:33] <StevenK> Er, what guts? I set up a bunch of variables and then call named_post?
[02:35] <wallyworld_> so you want to separate out the concerns. hooking into a choice selection and doing the xhr call are separate things. in the sharing stuff where i've used a mvc approach, the onsave published an event which the controller subscribes to and these aspects are separately tested. here,  a separate method would be sufficient
[02:36] <wallyworld_> out code has too much of this stuff in it - it's an anti pattern which would be good to eliminate
[02:37] <wallyworld_> another argument - it's very much like visual basic eeewwww
[02:37] <StevenK> wallyworld_: Sure, but I don't see what value that gets us. The guts are in ChoiceSource and the save() function is quite small.
[02:38] <wallyworld_> how do you test the save action then without invoking the popup? you can't
[02:38] <wallyworld_> your unit tests are compromised
[02:38] <StevenK> But how can I, it needs the data from the popup
[02:39] <wallyworld_> you test the separate method by passing in data you provide and such data is as per what the popup would provide
[02:39] <StevenK> So you want more tests?
[02:40] <wallyworld_> one more would be needed if the logic were separated out
[02:40] <StevenK> And I here I was thinking that two days writing JS tests was enough.
[02:41] <wallyworld_> depends what you want. spagetti ish code of properly constructed mvc style code
[02:41] <wallyworld_> s/of/or
[02:41] <wallyworld_> it would be good if we could start avoiding some of the mistakes of the past for new work
[02:42] <wallyworld_> if i were writing this, i wouldn't even be using a namespace, i'd use proper yui widgets
[02:43] <StevenK> That last comment makes me feel SO much better
[02:43]  * StevenK goes to grab lunch
[02:44] <wallyworld_> sorry, i was just trying to say that it's ok to compromise on some things, but if we do let's get the structure right
[02:44] <wallyworld_> i only just recently started using yui widgets as they were intended myself
[04:29] <lifeless> hah
[04:29] <lifeless> https://launchpad.net/~lifeless/+participation is buggy
[04:29] <lifeless> shows owner as member
[04:29] <lifeless> now, is the bug filed
[04:38] <lifeless> flacoste: we might want to consider removing https://launchpad.net/~rosetta-alpha, the distinction vs beta is perhaps unneeded?
[04:47] <wgrant> lifeless: There's also ~launchpad-recipe-beta
[04:48] <StevenK> LOL
[04:50] <lifeless> indeed
[05:50] <StevenK> Sigh, now the tests say no JS
[06:03]  * StevenK stabs setup_privacy_notification for being so crap
[06:06] <StevenK> wallyworld_: Hai
[06:07] <StevenK> Three days on JS tests. /wrists
[06:21] <StevenK> wallyworld_: MP updated.
[06:23] <wallyworld_> StevenK: thanks, looking
[06:28] <wallyworld_> StevenK: looking good. test_information_type_save_success has stuff commented out. plus
[06:28] <wallyworld_> test_save_information_type - you need to provide a success response and check that save_success is called
[06:28] <wallyworld_> i can point you at some examples
[06:29] <wallyworld_> test_perform_update_information_type still has the mockio calls which aren't needed there - you just need to ensure that the save is called
[06:30] <wallyworld_> same technique as checking save_success called in test_save_information_type
[06:32] <wallyworld_> see _test_delete_confirmation in test_bugtask_delete for an example of monkey patching a method to ensure it's called
[06:38] <StevenK> Damn it, I thought I had finished with the tests
[06:38] <StevenK> And then you point out I still had stuff commented out :-(
[06:39] <StevenK> And I'm back to null isn't an object.
[06:39]  * StevenK slams his head through his desk a few times
[06:39] <wallyworld_> sorry :-(
[06:40] <StevenK> I'm sick of this branch
[06:41] <wallyworld_> i don't blame you
[06:43] <StevenK> var node = this._node; and node is null? :-(
[06:43] <wallyworld_> which code is that from?
[06:44] <StevenK> anim.js
[06:44] <wallyworld_> that means that one of the nodes or selectors passed to choiceedit is not defined and so the resulting node is null
[06:44] <StevenK> It's calling display_privacy_notification() and dying
[06:45] <wallyworld_> let me find that method
[06:47] <wallyworld_> initial thought - one way to solve this is to add some dummy nodes to the html harness
[06:47] <wallyworld_> the ones which display_privacy_notification tries to find and flash
[06:48] <wallyworld_> or stub out the call to that method and just check that it has been called
[06:48] <StevenK> I thought I'd done enough, but I can't figure out what node the privacy notification is trying to grab and failing
[06:48] <wallyworld_> one thing it looks for is a node with class "global-notification"
[06:48] <wallyworld_> that is probably a div or something
[06:49] <StevenK> wallyworld_: Would you prefer I stub it out, or fix it to work?
[06:49] <wallyworld_> easiest to just add the fake nodes to the html harness
[06:49] <wallyworld_> less work
[06:49] <StevenK> I think it's easier to stub the fucker out, given I've been fighting with this for hours.
[06:50] <wallyworld_> to stub it out, you need to monkey patch it and then add it back at the end of the test, so about 6 or 7 lines of js
[06:50] <wallyworld_> vs one line of html per node
[06:50] <wallyworld_> of which there are perhaps 2 or 3
[06:51] <wallyworld_> StevenK: want me to finish off the branch for you?
[06:51] <StevenK> I've done the stubbing out for save_information_type
[06:51] <StevenK> And I've added the div to HTML
[06:52] <StevenK> Node is still null after adding div class="global-notification"
[06:52] <StevenK> I'm tempted to stub it out. We don't want to test it here.
[06:53] <StevenK> If it's called and the body has a private class, we're good.
[06:53] <wallyworld_> ok, whatever is easiest at this stage :-) i'm handwaving a bit
[06:57] <StevenK> And working.
[07:02] <StevenK> wallyworld_: Diff updated.
[07:05] <StevenK> wallyworld_: Pushed another change to completly drop mockio from test_perform_update_information_type.
[07:18]  * wallyworld_ looks
[07:28] <StevenK> wallyworld_: Still looking?
[07:29] <wallyworld_> StevenK: yeah, bigjools distracted me
[07:29] <StevenK> wallyworld_: Oh, did you want me to add back the library_exists test? I removed it because I thought it was a stub test just to show how to write one.
[07:30] <wallyworld_> StevenK: theoretically it should be there
[07:30] <StevenK> wallyworld_: I'll resurrect it
[07:30] <wallyworld_> it ensures the module is correctly declared/defined
[07:32] <wallyworld_> StevenK: test_perform_update_information_type - the function stub should assert that the passed in value is as expected
[07:32] <wallyworld_> Y.Assert.areEqual(xxx, value)
[07:34] <StevenK> wallyworld_: Okay, anything else?
[07:35] <wallyworld_> don't think so. i'm about to approve :-) sorry to be picky about it earlier. i think the tests are great now
[07:36] <wallyworld_> i would ask for a save success test where the privacy banner were hidden but you'l lkill me :-)
[07:36] <wallyworld_> to compliment the one where it is shown
[07:37] <StevenK> Grrr.
[07:38] <wallyworld_> it should just be a cut'n'paste where s/show/hide :-)
[07:38] <StevenK> And hasClass('public')
[07:39] <wallyworld_> yeah
[07:39] <wallyworld_> r=me anyway. fix if you want :-) if you do fix, the tests then provide good coverage
[07:40] <wallyworld_> and the extra test ensures that we have covered private being turned on and off and the page is updated as expected
[07:40] <StevenK> Yes, I've just finished adding it
[07:41] <wallyworld_> thanks. i bet you can't wait to do another javascript branch!!!
[07:43]  * StevenK wraps his mouse cord around his neck and pulls very very tightly.
[07:44] <StevenK> Oh, damn it!! My mouse is cordless!
[07:44]  * bigjools hands StevenK some rope
[07:44]  * nigelb hands StevenK some noodles.
[07:45] <StevenK> Noodles? How do they help?
[07:45] <StevenK> And gee, two people helping me commit suicide.
[07:45] <StevenK> I'm not sure if I should be touched or disgusted.
[07:45] <nigelb> You probably don't need help. You work on LP :P
[07:45]  * nigelb runs away
[07:46]  * StevenK points nigelb to https://dev.launchpad.net/Contributions
[07:46] <nigelb> Dammit.
[07:46] <nigelb> Wat. I'm still 4th. Needs fixing.
[07:47] <StevenK> 3 more landing
[07:47] <StevenK> s
[07:47] <nigelb> 3 more landings which delete code. That's a bigger challenge.
[07:48] <StevenK> Not really
[07:49]  * StevenK finally throws portlet at ec2
[07:49] <bigjools> I am currently working with Django.  It might be worse than LP.
[07:50] <wgrant> In parts.
[07:50] <nigelb> bigjools: You don't work on LP anymore?
[07:50] <nigelb> (MAS?)
[07:50] <bigjools> nigelb: haven;t  been since January, I was doing MAAS.  Start part of LP team though.
[07:50] <bigjools> Start?  Still*
[07:51] <nigelb> bigjools: Oh. Interesting. Did not know.
[07:51] <czajkowski> StevenK: have you seen this weeks desktop image the chunkey has been removed
[07:51] <StevenK> czajkowski: I have fear.
[08:02] <adeuring> good moorning
[08:02] <czajkowski> StevenK: less scary
[08:02] <czajkowski> adeuring: ello
[08:03] <czajkowski> best tool ever evented - listadmin
[10:24] <StevenK> czajkowski: How so? (Re: G+)
[10:27] <czajkowski> StevenK: https://plus.google.com/photos/102921374554385564572/albums/5730819334465556225/5734582582300875890  is niec and innocent looking without the scary chunkey
[10:27] <StevenK> czajkowski: I meant your PPA comment
[10:28] <czajkowski> StevenK: how ws I gonna work that out now really :)
[10:29] <czajkowski> StevenK: each time I get to figure out an answer for one, a new one comes up and wgrant points out its the user not the ppa
[10:29] <czajkowski> but until that happens I go around in cirlces wondering wtf is up with the ppa
[10:30] <wgrant> The trouble with letting people run code as part of a feature is that they come up with infinitely many different failures to blame on us :)
[10:30] <czajkowski> wgrant: like the one last night whouc pointed out WRONG ANSWER
[13:01] <deryck> Morning, all.
[13:03] <rick_h> morning deryck
[13:03] <deryck> I've had all I can take of these doc tests.
[13:04] <deryck> They will die today.
[13:04] <rick_h> hah
[13:13] <czajkowski> deryck: and good morning to you
[13:50] <stub> ImportError: No module named convoy.meta
[13:50] <StevenK> Your deps are out of date.
[13:56] <rick_h> StevenK: are you avail next monday night for our convoy call? I need to reset that back up after the utter failure last time
[13:58] <StevenK> rick_h: I don't see an issue with that
[13:58] <rick_h> StevenK: ok, will send out a new email shortly then and see if I get any replies.
[13:59] <StevenK> rick_h: Perhaps you should chat to the others first. I'm happy to fit in with them.
[13:59] <StevenK> And if that doesn't work, get deryck to poke their managers until they squeal.
[14:00] <rick_h> hah will do
[14:00] <StevenK> rick_h: However, convoy 0.2.4 is in our PPA
[14:00] <rick_h> StevenK: is it? last I knew I still broke the build
[14:00] <rick_h> with my makefile that does make test first
[14:00] <StevenK> I fixed that.
[14:00] <rick_h> ah, I'll look then, ty much
[14:00] <StevenK> Your Makefile is sort of pointless, but meh
[14:00] <rick_h> StevenK: yea, but I've got vim shortcuts and such to auto make test and things
[14:01] <rick_h> so standard + place + handy
[14:37] <sinzui> mrevell, ping
[14:38] <sinzui> jcsackett, ping
[14:38] <jcsackett> sinzui: pong.
[14:39] <sinzui> jcsackett,  how goes the day?
[14:39] <jcsackett> sinzui: alright. looking into cleaning up code mess i noticed on last week's branches. you?
[14:40] <mrevell> hey sinzui. Thanks for the email and the LEP updates. I won't be able to look at them in detail until tomorrow afternoon.
[14:42] <sinzui> mrevell, I think https://dev.launchpad.net/LEP/PrivateProjects need a total rewrite. It talks mostly of what other leps do...my team cannot read that and know what to build?
[14:42]  * sinzui hopes he is not the only one who really knows what private projects are
[14:43] <mrevell> sinzui, I believe I have a good grasp of what we're looking to achieve with private projects, so I can do that rewrite.
[14:43] <sinzui> jcsackett, I am torn to write again, which depresses me, work on an entitlement queue mechanism, which depresses me, or return to ie8 which depresses me
[14:44] <jcsackett> sinzui: ugh.
[14:45] <jcsackett> sinzui: if it's just a case of not wanting to step on toes, there's the "Share None" card -- i don't think any of us are working on that.
[14:45] <sinzui> mrevell, I can delete the non-relevant parts of page, but i would limit myself to two hours to put what should be in the page.
[14:46] <sinzui> jcsackett, I think we can undertake it know that bogtaskflat is in place
[14:46] <jcsackett> sinzui: yeah, i think it's ready. i was just presenting it as something else you could do if you need a break from the three things you've been doing for weeks.
[14:47] <sinzui> I try not to make myself a part of the critical path because I need to be available/distractable at all times
[14:47] <jcsackett> sinzui: fair.
[14:53] <sinzui> jcsackett,  put a card on the board to describe the clean up.
[14:58] <jcsackett> sinzui: sure thing, thought i had.
[15:14] <gary_poster> jml, hey.  Hopefuly helpful heads up that does not bother us right now: when you install the current subunit trunk as built in a PPA, it builds subunit-filter to run with python3, which is broken.  subunit is not importable by python 3.  Do you want me to file this trunk packaging bug as a subunit software bug, or just leave this with you here on IRC, or...?
[15:25] <jml> gary_poster: trunk bug pleaose
[15:25] <gary_poster> ack jml will do
[16:13] <kirkland> is it possible to apt-mirror a private-ppa?
[16:13] <kirkland> I'm trying to use my private url with the name:pw embedded in it
[16:13] <kirkland> but that's not working
[16:16] <kirkland> nevermind, I think I found a hack
[17:29] <abentley> deryck: There's no OCR.  At your leisure, could you please review https://code.launchpad.net/~abentley/launchpad/archivejob/+merge/103331 ?
[17:29] <deryck> abentley, sure.
[17:30] <abentley> deryck: thanks.
[17:30] <deryck> np!
[17:31] <gary_poster> deryck, I'm seeing errors trying to import convoy (and thus breaking make) in a fresh build of r15141.  Do you know anything about this? I seem to recall you and maybe rick_h involved with convoy?  Probably completely wrong :-P but if you have any info I'd appreciate it
[17:31] <rick_h> gary_poster: it should be in the deps
[17:31] <deryck> gary_poster, rick_h and I are totally to blame :)
[17:32] <rick_h> no new issues with it in some time, last change was > month ago
[17:32] <rick_h> gary_poster: any more details on error?
[17:32] <gary_poster> rick_h, deryck :-)
[17:32] <gary_poster> this is in parallel testing, which has similarly been running fine for some time
[17:32] <gary_poster> for some definition of fine ;-)... *this* has been fine
[17:32] <deryck> heh
[17:32] <rick_h> gary_poster: gotcha, I know SteveK did update the PPA build last night to fix the build
[17:33] <rick_h> so guess there is a change recently, I lied
[17:33] <deryck> gary_poster, yeah, maybe update packages?
[17:33] <gary_poster> deryck, this is as of a completely fresh ec2 instance created and initialized from scratch about 4 hours ago.  rick_h this doesn't tell me much new :-) http://pastebin.ubuntu.com/944439/
[17:34] <gary_poster> so is this supposed to be installed via debs?
[17:34] <rick_h> looking
[17:34] <rick_h> gary_poster: yea, it's pulled from lp's ppa
[17:34] <gary_poster> ok, lemme run with that for a second...
[17:34] <rick_h> gary_poster: so yea, just looks like it's not installed atm.
[17:35] <dhillon-v10> hi all, I have a quick question about launchpad PPA's: so i just finished compiling a custom kernel and the whole process resulted in 2 debian packages, the kernel contains a debian folder with all the make files and stuff, now if I upload the patched source to launchpad will it build the kernel for me and let me download the debs?
[17:35] <gary_poster> rick_h, appears to be! http://pastebin.ubuntu.com/944443/
[17:36] <abentley> deryck: Could you please run "select count(*) from archivejob" against the staging DB?
[17:36] <gary_poster> this is in on lucid (that is, in a lucid lxc container) fwiw
[17:36] <rick_h> gary_poster: hmm, yea so that's the right version and eveyrthing
[17:37] <deryck> abentley, sure.  give me two seconds.... new connect command IIRC and haven't run it yet.  consulting mail....
[17:37] <rick_h> gary_poster: can just a normal python shell can you import convoy.meta? Guessing path issue?
[17:37] <gary_poster> rick_h, no, you can't
[17:37] <gary_poster> http://pastebin.ubuntu.com/944449/fwiw
[17:37] <gary_poster> heh http://pastebin.ubuntu.com/944449/
[17:38] <rick_h> gary_poster: ok, give me a sec to update my local install and see if it's something I can get due to recent package update
[17:38] <gary_poster> thx
[17:39] <deryck> abentley, 0 results.
[17:39] <abentley> deryck: Thanks.  So the odds are that there are no rows on production either...
[17:39] <rick_h> doh, not getting issue getting an updated python-memcache? Anyone else seen this via rocketfuel-get?
[17:40] <rick_h>   Getting distribution for 'python-memcached==1.49DEV-r57'.
[17:40] <rick_h> sorry Error: Couldn't find a distribution for 'python-memcached==1.49DEV-r57'.
[17:40] <deryck> abentley, yeah, good odds.
[17:40] <deryck> rick_h, update download cache?
[17:43] <gary_poster> rick_h, suspicious? http://pastebin.ubuntu.com/944455/
[17:43] <rick_h> deryck: got it, yea don't know what that didn't update
[17:44] <rick_h> gary_poster: yea, seems to be missing the python bits :/
[17:44] <gary_poster> exactly
[17:44] <rick_h> guessing the StevenK update package lost some files
[17:44] <deryck> rick_h, cool
[17:45] <gary_poster> seems like it
[17:45]  * rick_h goes to see if it's possible to see what changed
[17:46] <rick_h> gary_poster: so I'll work with stevek on that. Is it possible for you guys to cheat and pull the python package just to unblock you?
[17:46] <rick_h> http://pypi.python.org/pypi/convoy/0.2.4
[17:47] <gary_poster> rick_h, may I leave this with you for now?  Please ping me if you'd like me to help, and also please ping me if you find a resolution.  Also, if you verify the problem we probably should send a note to launchpad-dev so others know what is going on.  pulling the Python package: not easy because we're testing LP trunk, and rebuilding every time :-P If it starts to be really painful we can make our own branch of trunk
[17:47] <gary_poster> I guess
[17:47] <gary_poster> but it is kind of a big deal to us
[17:47] <gary_poster> not gigantic
[17:47] <gary_poster> but not small :-)
[17:48] <rick_h> gary_poster: yea, I'm just not 100% sure how this is setup since SteveK has been doing it from the start.
[17:48] <gary_poster> gotcha rick_h
[17:48] <rick_h> I've handled all the python and he all the packaging
[17:48] <gary_poster> cool
[17:48] <rick_h> gary_poster: definitely, I'll send an email to -dev
[17:48] <gary_poster> cool thanks rick_h.
[17:49] <rick_h> thanks for the heads up, sorry for the borkage
[17:49] <gary_poster> np, welcome
[18:51] <abentley> deryck: Could you also please review https://code.launchpad.net/~abentley/launchpad/celery-everywhere-6/+merge/103346 ?
[18:52] <deryck> abentley, sure.
[18:52] <deryck> abentley, I'll get them before I EOD.
[18:53] <abentley> deryck: okay.
[19:06] <deryck> sinzui, ping
[19:09] <deryck> sinzui, unping, I just found it.
[19:09] <deryck> weird how to happens. :)
[19:10] <deryck> s/to/that/
[19:11] <flacoste> lifeless: time for a chat?
[19:13] <lifeless> flacoste: still doing just-got-up-thing, will ping you in a couple of minutee
[19:13] <lifeless> s
[19:14] <flacoste> lifeless: ack
[20:51] <deryck> abentley, r=me on both MPs.
[20:52] <abentley> deryck: Thanks!
[20:53] <deryck> abentley, np!