[09:31] <danilos> gmb, hi, fwiw, I haven't really done much checklist CHR going through entire staging-is-not-updating dance with people
[09:32] <gmb> danilos: Okay. I'll go through the checklist now, in that case.
[09:32] <danilos> gmb, thanks
[09:37] <gmb> danilos: Where is this fabled checklist? All I can find is the Answer Contact stuff on the wiki and the old CHR FAQ.
[09:47] <danilos> MaintenanceRotationSchedule on dev.l.n, included in email from Gary
[09:56] <gmb> danilos: Or hey,  I could actually look at my fricking email. Jeez.
[09:56] <gmb> Sorry. Not with it this morning.
[10:39] <gmb> Right, checklist taken care of.
[11:05] <danilos> gmb, heh, sorry about it, I was trying to deal with a million things myself
[11:31] <gmb> danilos: No worries. Didn't take all that long except for the project review stuff, and that's only because there's no way to filter out project where we're waiting on the owners to get back to us.
[12:12]  * gmb lunches
[13:24] <gary_poster> danilos, hey.  Do you think I need to move the style from style.css to 3.0 css?  New stuff has gone into style.css too AFAIK.  I thought the distinction was that pillar-specific stuff went into style.css and LP-wide stuff went into 3.0, but I see now that this is not really the case: 3.0 has application stuff at the bottom, though it complains about it.
[13:24] <danilos> gary_poster, hi, I might be wrong then, I thought it was all to go into style-3.0.css
[13:25] <gary_poster> FWIW, if you don't think so, my default position will be to land as is.  I think the CSS story is not fully worked out
[13:25] <danilos> gary_poster, at least originally I thought sinzui wanted it all clean and in 3.0 for new stuff
[13:25] <danilos> gary_poster, oh, definitely land as-is
[13:25] <gary_poster> (for instance, the stuff at the bottom of 3.0 saying we should use application specific files, but then every pillar we have, or just about, including registry, has something there)
[13:25] <gary_poster> ok cool thanks :-)
[13:25] <danilos> gary_poster, we should probably just come up with a clean per-app CSS story anyway
[13:26] <gary_poster> yeah
[13:26] <gary_poster> if we have that, then it is clear
[13:26] <gary_poster> heh, except for the fact that pillars touch on other pillars, especially registry :-P
[13:27] <danilos> yeah, it always gets murky, but we can always include extra CSS where needed in the template
[13:27] <gary_poster> so putting it all in a global file isn't particularly crazy in that case...
[13:27] <gary_poster> yeah
[13:27] <danilos> also, splitting it for development and combining it for users is never a bad idea either :)
[13:28] <gary_poster> yeah, that too
[13:28] <gary_poster> oops
[13:28] <gary_poster> bac benji danilos gmb: kanban now, call RSN
[13:28] <gmb> k
[13:50] <gmb> gary_poster: Would you have any objection to me taking the first week of August as leave, then, given that we don't actually have anything other than a vague timeframe for a sprint?
[13:52] <gary_poster> gmb, not at all
[13:52] <gmb> gary_poster: Excellent. I'll submit the request to CA now, before anything changes :)
[13:52] <gary_poster> good plan :-)
[13:53] <gmb> gary_poster: Done.
[13:57] <gary_poster> gmb, approved
[13:57] <gmb> Thanks
[14:42] <gary_poster> running to dr; back in a bit over an hour
[16:08]  * danilos -> out
[17:35]  * gmb -> out
[19:43]  * gary_poster is spoiled by not having to deal with TAL + JS
[19:44] <gary_poster> TAL + JS is so much less nice
[19:44] <gary_poster> or...
[19:44] <gary_poster> trying to build the non-JS and JS stories simultaneously is what I really mean
[19:44] <gary_poster> JS only is much nicer
[19:48] <benji> yep; I've been surprised by how non-painful building HTML with YUI has been
[20:00]  * benji embarks on CHR.
[20:01] <benji> Day 2: the foriegn terrain seems less hostile as we set out today, but who knows what fierce creatures we will encounter.
[20:11] <benji> bac: you know things about commercial accounts, right?  There is an activation request in the commercial support RT and from my reading of https://wiki.canonical.com/Launchpad/UserRequestsCheatSheet I should just tell mrevell about it
[20:11] <benji> ...but that seems sort of silly, why would we monitor that RT if he's the one that will be doing things.
[20:11] <bac> benji: i don't know
[20:12] <bac> is that the one that was there yesterday?  that one he seemed to have claimed
[20:12] <benji> I'll ask him then.  Thanks anyway.
[20:12] <benji> nope, this one was filed right at an hour ago
[20:12] <bac> know, i mean "i don't know why we monitor it".  we really don't want the whole team mucking with project set up
[20:12] <bac> s/know/no
[20:12] <benji> oh, but he's probably AFK; I'll send him an email
[20:13] <benji> ah
[20:13] <bac> benji: can i ask you about credentials and lplib?
[20:13] <bac> i've got a system-wide credential for my machine to staging
[20:13] <benji> I live for such moments.
[20:14] <bac> i'm trying to use a product that grabs that set of credentials even though the SERVICE_ROOT is for production, not staging
[20:14] <bac> so, it is directing the requests to staging
[20:14] <bac> does that make sense?
[20:15] <benji> the words make sense, the behavior does not
[20:15] <bac> the second part of my question, is how do i kill existing credentials?  i looked in seahorse but don't see them
[20:15] <benji> they should be shown in seahorse; they may not jump out at you though.  Let me see if I can give you a hint.
[20:17] <benji> it is probably listed as "network password" if you double-click on it and look at the various tabs that come up you should be able to verify that it's the one you want
[20:23]  * bac looks
[20:31] <bac> benji: so i found my keys in seahorse but they were only for production.  so i'm not sure why this lplib app is trying to connect to staging even thought the credentials and the SERVICE_ROOT are for production.  odd.
[21:29] <bac> benji: did you email mrevell about the RT situation?  i hope he'll address it generally.
[21:29] <benji> yep
[21:30] <gmb> gary_poster: Around?
[21:31] <gary_poster> gmb, hi, yes
[21:32] <gmb> gary_poster: Hi. Any chance we can bring our call forward by 30 minutes tomorrow or postpone it until Friday? I need to leave at about 13:45UTC tomorrow for an appointment.
[21:33] <gary_poster> gmb, either is fine.  I'm inclined to 30 minutes earlier, but if you could simply move the appointment on Google calendar to the time you'd prefer then it should work for me
[21:33] <gmb> gary_poster: Ok. 30 minutes earlier works fine for me. I'll update the calendar.
[21:34] <gmb> Thanks
[21:34] <gary_poster> cool thanks
[21:42] <bac> benji: found the problem.  it is an error in the app.
[21:43] <benji> good... I guess :)
[21:43] <benji> is it an error that others are likely to have?  is there something we can do to make that mistake less likely?
[22:23] <bac> benji: i'm not sure if lplib moved out from under this code or if it was never correct
[22:24] <bac> the problem is the constructor for a Launchpad object has three required params and several optional.  they passed some of the optional params in the wrong position, so the service root was not getting set and using staging, the default
[22:24] <bac> so, no, i don't think it is a general problem *unless* the constructor was changed to add those extra required params
[22:24] <bac> which would be unfortunate
[22:55] <benji> bac: there have been some changes there, but that doesn't sound like anything I remember...oh!  I do remember something.  I /think/ the Launchpad constructor was never meant to be a public API.
[22:55] <benji> I also have to go now.  I'll dig into this a little more tomorrow.
[22:56] <bac> thanks.  i'll look into it in the morning