[00:46] <huwshimi> I really, really, really, really wish we had an A/B testing framework in Launchpad
[00:48] <rick_h_> heh, do we have the metrics to be able to put A/B testing to use?
[00:49] <huwshimi> rick_h_: That's what I mean
[00:50] <huwshimi> we have feature flags that could be used to set up the A and B, but we need random user assignment and result reporting to make it useful
[00:51] <rick_h_> yea, it's a tough product to define what metric we'd want for each A/B case
[00:52] <rick_h_> what's the current use case?
[00:52]  * rick_h_ is bored and curious
[00:54] <huwshimi> rick_h_: A proper a/b testing framework allows you to hook in tests for results. The test could be "number of people who get to a certain page" or "number of people who click a link" etc.
[00:56] <rick_h_> huwshimi: yea, but LP is so different depending on who visits/use case that it's a bit fun to think of what would be better
[00:57] <huwshimi> rick_h_: Isn't that the point of doing an A/B test?
[01:00] <huwshimi> poolie: Could the feature flags system be modified so that instead of showing to a group it could pick users at random?
[01:00] <poolie> sure could
[01:01] <poolie> i would like that very much
[01:01] <poolie> there is a bug asking for it
[01:01] <huwshimi> poolie: Ooh
[01:01] <poolie> i am happy to either help or to be bribed/distracted in to doing it
[01:01] <poolie> but i need to go out and do some trip prep stuff so probably not today
[01:03] <huwshimi> poolie: Wow, ok, this makes getting an A/B testing framework possible. It would be farily easy to write the javascript data collection side of things
[01:04] <poolie> the other thing we need is to log it somehow
[01:04] <poolie> either from the http server or something else
[01:04] <poolie> maybe js
[01:04] <huwshimi> poolie: Yes, there would need to be an AJAX call to log the resaults
[01:05] <huwshimi> *results
[01:25] <huwshimi> rick_h_: Are you still around?
[01:25] <huwshimi> rick_h_: If you are, I have a conflict when I merge your changes for the loading notification. Any ideas? http://paste.ubuntu.com/754337/
[01:26] <rick_h_> huwshimi: looking
[01:26] <huwshimi> rick_h_: Cheers
[01:27] <rick_h_> huwshimi: bah, yea I moved a couple things that it's not liking, sec
[01:27] <huwshimi> np
[01:28] <rick_h_> huwshimi: http://paste.mitechie.com/show/455/ is what it should be. That's merged with rocketfuel-get this evening so should be up to date
[01:29] <huwshimi> rick_h_: Cheers :)
[01:30] <huwshimi> rick_h_: Hmm... I lose the order/config bar completely
[01:30] <rick_h_> huwshimi: make sure that your css combo script in bin gets updated.
[01:31] <rick_h_> huwshimi: yea, make sure the css combo script is updated and you've got "indicator" css in the combo
[01:31] <huwshimi> ah I see
[01:34] <huwshimi> hmmmm....
[01:37] <huwshimi> rick_h_: Still nothing
[01:37] <huwshimi> rick_h_: The indicator css is there and working
[01:37] <rick_h_> huwshimi: any hints?
[01:37] <huwshimi> rick_h_: But still no order bar
[01:38] <huwshimi> rick_h_: The order bar div is completely empty
[01:38] <huwshimi> oh wait, I have js errors
[01:38] <StevenK> poolie: I'm a little unsure about the branch you've put up
[01:38] <rick_h_> huwshimi: ok, cool. Maybe typo in cleaning up the merge?
[01:38] <StevenK> poolie: It looks mostly UI related, so I'd prefer huwshimi look it over.
[01:40] <poolie> StevenK, ok with me, huwshimi do you mind?
[01:40] <poolie> he reviewed the predecessor anyhow
[01:40] <poolie> btw i'm happy to say google is now apparently enjoying the results of the microformat work
[01:40] <huwshimi> poolie: Sure, mind linking me to the mp?
[01:41] <StevenK> huwshimi: https://code.launchpad.net/~mbp/launchpad/888353-microformats-2/+merge/83856
[01:41] <huwshimi> StevenK: Thanks
[01:41] <huwshimi> I'll take a look soon
[01:42] <poolie> thanks
[01:42] <poolie> ok i'm out for a bit, see you later
[01:44] <huwshimi> rick_h_: on this line "this.set('model', new namespace.BugListingModel({" it says undefined is not a function""
[01:44] <rick_h_> huwshimi: in chrome?
[01:45] <huwshimi> rick_h_: yea
[01:45] <rick_h_> try on firefox in case you're hitting the chrome issue
[01:45] <rick_h_> there's a known chrome issue that is in progress of rollback/fix
[01:45] <rick_h_> unrelated to the spinner
[01:46] <rick_h_> but BugListingModel is defined in line 37, and this sholdn't be undefined, so not sure what it's not liking there
[01:48] <huwshimi> rick_h_: Firefox says: "namespace.BugListingModel is not a constructor"
[01:49] <rick_h_> huwshimi: can you pastebin your whole file then? Something is up. It's defined back in 52
[01:49] <rick_h_> huwshimi: http://paste.mitechie.com/show/456/ if you want to rnu diff locally
[01:51] <huwshimi> rick_h_: Oh, something's very wrong with my file. It's about 70 lines shorter :)
[01:51] <rick_h_> huwshimi: ah ok. Yea, that'll do it
[01:51] <huwshimi> oh, there we go.
[01:51] <huwshimi> rick_h_: just pasted over your new file and it works now. Thanks :)
[01:51] <rick_h_> huwshimi: re-pushing my branch is case I missed somehting
[01:52] <rick_h_> huwshimi: ah ok
[01:53] <huwshimi> rick_h_: Thanks, I might grab your new branch. This is still not working for me.
[01:53] <huwshimi> (in other ways now)
[01:53] <rick_h_> huwshimi: ok, yea should just be able to  bzr branch bzr+ssh://bazaar.launchpad.net/~rharding/launchpad/buglists-loading-885272/
[01:54] <rick_h_> into your lp-branches dir, update the links, and then make run
[01:55] <huwshimi> rick_h_: Have you just remerged the branch with devel?
[01:55] <rick_h_> huwshimi: sec I will
[01:55] <rick_h_> did it this afternoon, but will redo a rocketfuel-get on it and repush
[01:55] <huwshimi> cheers
[01:56]  * rick_h_ is still figuring out how best to work around stuff
[01:56] <StevenK> rick_h_: rf-get in your devel branch, and then bzr merge ../devel in your other branch
[01:57] <rick_h_> huwshimi: ok, updated and pushed
[01:57] <huwshimi> rick_h_: Cheers mate
[01:57] <rick_h_> StevenK: ok, I've been doing some rf-get right in my branch itself, bad side effects?
[01:59] <StevenK> rick_h_: I'm not sure -- that ^ is how I work
[01:59] <rick_h_> StevenK: ok cool, thanks
[02:05] <huwshimi> rick_h_: You did push the changes? It might just be taking a whiel
[02:06] <huwshimi> *while
[02:06] <rick_h_> huwshimi: yes, I pushed but "No new revisions or tags to push."
[02:06] <rick_h_> so shouldn't be anything new there if you're waiting for new files
[02:07] <huwshimi> rick_h_: And you did an update of devel (or rocketfuel-get) before you merged devel with your branch?
[02:08] <huwshimi> rick_h_: Only checking cause when I merge your changes with a fresh branch I get a conflict
[02:08] <rick_h_> huwshimi: yes, on rev 14404
[02:08] <StevenK> jtv: O hai! https://code.launchpad.net/~stevenk/launchpad/death-to-lazr-testing-tales/+merge/83889
[02:08] <jtv> hi
[02:09] <jtv> Does that come with coffee?
[02:09] <StevenK> Pft, it's +1/-19, like it needs any
[02:09] <jtv> I don't care what it needs.  It's what I need that counts.
[02:09] <rick_h_> huwshimi: ah, sec
[02:11] <wgrant> lifeless: As long as we link to the final page.
[02:11] <wgrant> I guess.
[02:11] <wgrant> We probably need to redirect.
[02:13] <lifeless> wgrant: ECONTEXT
[02:13] <wgrant> ML archives.
[02:13] <wgrant> We can't just show the oldest message by default.
[02:13] <StevenK> jtv: Haha
[02:13] <wgrant> We would have to default to the last page.
[02:13] <lifeless> we can show the list of indices.
[02:14] <jtv> StevenK: it's not funny.
[02:14] <wgrant> lifeless: Hm?
[02:14] <lifeless> like $every $other $mhonarc $site $out $there
[02:14] <wgrant> That's no argument.
[02:14] <rick_h_> StevenK: what make do I need to do db updates?
[02:14] <wgrant> mhonarc is pretty terrible. Basing arguments on what its other users do is illy.
[02:14] <wgrant> s
[02:14] <lifeless> its other users are using it as it was intended
[02:15] <lifeless> I notice now that we don't have monthly groupings
[02:15] <rick_h_> huwshimi: looks like I'm learning new stuff. rocketfuel-get only updates devel, no matter if it's run from another branch. So merging and resolving now
[02:15] <lifeless> so its all messages ever that get reindexed
[02:15] <StevenK> rick_h_: To get them rolled out, or to make them?
[02:15] <lifeless> wgrant: so most static archiver sites have a page that says
[02:15] <lifeless> 'jan 2001'
[02:15] <rick_h_> roll out to my local db, I've gotten changes from devel and getting missing column oops
[02:15] <lifeless> 'feb 2001'
[02:15] <lifeless> etc
[02:16] <rick_h_> StevenK: ^^ sorry
[02:16] <lifeless> I'm proposing we in the interim, link to that
[02:16] <StevenK> rick_h_: Oh, 'make schema'
[02:16] <rick_h_> StevenK: ty
[02:17] <huwshimi> rick_h_: Ah, yes it does. Sometimes you'll get pqm errors if you have conflicts. If you have branches that have been hanging around for a while it's good to do a devel merge just to resolve any issues before you submit for testing
[02:17] <wgrant> lifeless: Well, we don't have such a page, but OK.
[02:17] <lifeless> wgrant: I'm fairly sure mhonarc knows how to make one
[02:18] <rick_h_> huwshimi: yea, and this was pulled from deryck's branch so no idea how old it is to start out
[02:18] <huwshimi> rick_h_: Yeah, that's where it gets hairy. You can always do a devel merge to be sure.
[02:20] <rick_h_> oh boo, reset my db so lost my feature flags
[02:21] <huwshimi> rick_h_: Don't you hate that :)
[02:22] <rick_h_> ok, wtf...all my code is gone now
[02:22] <rick_h_> bah, this is probably due ot the rollback or osmething arggg
[02:25] <wgrant> StevenK: Your sorting in the canonical.lazr branch is wrong.
[02:25] <wgrant> subunit, lazr, testools
[02:26] <rick_h_> huwshimi: ok, pushing changes, gets rid of the js error
[02:26] <rick_h_> working on getting records back in db so I can test the actual paging and such, but think that might do it
[02:28] <rick_h_> huwshimi: ok, tests that it works now
[02:43] <StevenK> wgrant: Oh sigh
[02:43] <StevenK> wgrant: Fixed.
[02:43] <huwshimi> rick_h_: perfect, all working now :)
[02:44] <rick_h_> huwshimi: awesome, thanks for your patience withme
[02:44] <huwshimi> rick_h_: No, no, all good!
[02:44] <StevenK> rick_h_: Write a script to populate the db.
[02:44] <StevenK> rick_h_: Or 'make iharness' at a pinch
[02:44] <rick_h_> StevenK: yea, on my todo
[02:44] <rick_h_> haven't peeked at the db much yet
[02:45] <StevenK> Don't look too close, your eyes will bleed.
[02:45] <rick_h_> StevenK: was actually thinking I need to look at the api and see if I can script stuff using that instead
[02:45] <rick_h_> StevenK: heh yea, most dbs, and with this one being a bit old, I bet there's some scary in there
[02:46] <StevenK> rick_h_: So if you're populating objects to test and play, I'd suggest you just write a script that makes use of LaunchpadObjectFactory.
[02:47] <huwshimi> rick_h_: Just going to eat some lunch and then send through some feedback for you
[02:47] <StevenK> rick_h_: For example, I want a product, I don't care what it is: product = factory.makeProduct()
[02:47] <rick_h_> StevenK: ok cool, will look it up, taking notes
[02:48] <StevenK> rick_h_: LaunchpadObjectFactory is what is used in tests when you see self.factory...
[02:49] <rick_h_> ah makes sense, I've really only done much on the JS side of things so far.
[02:49] <StevenK> Haha, I've tried to stay away from the JS side of things.
[03:06] <wallyworld_> lifeless: we show private teams in the bug subscriptions portal (it used to oops but now fixed). but we explicitly filter out private teams from the branch subscription portal. should we be consistent here?
[03:06] <wallyworld_> nb we filterout private teams the user cannot see
[03:07] <wallyworld_> but we now have a mechanism for rendering private teams even if the user cannot see them
[03:08] <lifeless> so, AIUI the new rules we are saying that subscribing to an object discloses the team
[03:09] <lifeless> so yes, they should be shown; OTOH have we fixed up any erroneous (e.g. to public branches) subscriptions of private teams yet
[03:10] <wallyworld_> no, not afaik
[03:12] <lifeless> we probably want to address that before making the teams visible to any viewer of public artifacts
[03:14] <wallyworld_> i'd have to check - do we allow public bugs to have private subscribers?
[03:14] <wgrant> lalalalala
[03:15] <wallyworld_> since if we do allow it for public bugs, shouldn't we allow it for public branches also?
[03:15] <lifeless> I think wgrant means 'we have not implemented the UI/business rules around this area, nor around that of handlings privacy transitions of objects
[03:16] <wgrant> s/implemented/devised/
[03:16] <wallyworld_> so, what's the damage in allowing a viewer of a public branch to see that a private team is subscribed to the branch?
[03:17] <lifeless> there is none; as long as the private team was told they would disclose their existence
[03:17] <wallyworld_> sure. that's how it is now for bugs
[03:17] <wallyworld_> with the recent changes
[03:19] <wallyworld_> lifeless:  if we want to not expose any private subscribers, then i should stop work on this branch entirely, since we will be exposing the existence of private branch owners, reviewers, committers also
[03:20] <lifeless> wallyworld_: well we do, subject to the previously discussed caveats
[03:20] <lifeless> wallyworld_: which is that if someone doesn't want to be disclosed, they can't interact with the branch
[03:21] <wallyworld_> yes. that point never came up though in our standup when my work on this branch was discussed
[03:21] <lifeless> we probably need to refine the definition of interact too, to acknowledge that there are subscribers we don't know about (as anyone we notify could be a multiplier), and anyone that can see a page can poll it
[03:22] <lifeless> I will nab sinzui tomorrow about that
[03:22] <wallyworld_> so i guess i can complete the work andbefore landing we may need to do some other work
[03:22] <lifeless> you can just ff it perhaps
[03:23] <wallyworld_> could do, but it's already out there for bugs
[03:23] <wallyworld_> we just went ahead and deployed it
[03:24] <lifeless> heh
[03:24] <wallyworld_> not sure if any private teams have complained or noticed
[03:24] <lifeless> you probably want to check with sinzui
[03:24] <lifeless> I'm not in any position to second guess him - I haven't been tracking the detail on how you've been approaching this
[03:24] <wallyworld_> i sort of thought the policy was that it is now ok to expose a team's name / existence
[03:25] <wallyworld_> i'll check tomorrow
[03:25] <lifeless> my understanding is that we settled on 'when the team interacts with something' and 'team interactions will prompt to permit the interaction'
[03:25] <lifeless> its the second bit I suspect is missing
[03:25] <wallyworld_> yes
[03:26] <wgrant> The second bit requires an API break.
[03:26] <wgrant> In dozens of places.
[03:27] <wallyworld_> maybe we decided against it then. i can't recall
[03:27] <lifeless> I'd worry a little if we had
[03:28] <lifeless> because we have a number of policies intended to prevent accidental discovery of private team names
[03:28] <lifeless> and not doing the second bit will deeply devalue them
[03:28] <wallyworld_> my memory is fuzzy, so i'm not sure one way or the other
[03:29] <wgrant> I thought we were going to skip that, because of the enormous and ever-expanding scope creep it would entail.
[03:29] <wgrant> Given recent happenings, I don't think we need any more of that...
[03:29] <wallyworld_> i seem to recall that the discussion was that private team names could be exposed
[03:29] <wallyworld_> and that people would have to given them cryptic names
[03:29] <wallyworld_> if they didn;t want others to guess things
[03:34] <lifeless> noone told me :)
[03:35] <wgrant> We don't have a compelling, pretty, feasible private team design.
[03:35] <wgrant> We no longer have a compelling, pretty, feasible private artifact design.
[03:36] <wallyworld_> lifeless: perhaps we can all have a chat with sinzui tomorrow to clear it up. in case i/we have misunderstood anything
[03:38] <lifeless> sure
[03:38] <lifeless> I'm here all week :P
[03:38] <wgrant> Wait a sec.
[03:38] <wgrant> It's Wednesday.
[03:38] <wgrant> Why *are* you here?
[03:38] <lifeless> lynne told me off for frittering leave away :P
[03:38] <wgrant> Heh
[03:39] <wallyworld_> but you're here when you are on leave too
[03:41] <StevenK> wallyworld_: Multiple people have told lifeless at one time or another that he sucks at leave.
[03:42] <wallyworld_> i just think he is so attached to his nick that he would hate to not live up to it
[03:48] <lifeless> other way around
[03:48] <lifeless> the nick has to live up to me
[03:49]  * wallyworld_ wonders if lifeless is the chicken or the egg
[03:51] <StevenK> I can't use = to compare dates in postgres?
[03:51] <StevenK> (I don't care about the time)
[03:53] <lifeless> you can, but you'll need to cast to date first
[03:55] <StevenK> WHERE datecreated = '2011-11-30'::date; == 0 rows
[03:56] <StevenK> But max(datecreated) shows 2011-11-30
[03:56] <lifeless> datecreated isn't a date
[03:56] <lifeless> WHERE datecreated::date == '2011-11-30';
[03:56] <StevenK> Ah
[03:56] <lifeless> or (for more efficiently
[03:57] <lifeless> WHERE datecreated BETWEEN 2011-11-30 00:00 and 2011-11-30 23:59:59.99
[03:57] <lifeless> or something
[03:58] <StevenK> lifeless: I added a few things into the db using the factory and iharness and forgot to grab their names -- I just wanted the quickest way to grab the details
[03:59] <StevenK> Hm. members=[foo] has invited them
[04:02]  * StevenK wishes alert worked better with zsh
[04:20] <lifeless> so
[04:21] <lifeless> lazr_dbschema or lazr_postgresql ?
[04:21] <StevenK> The former
[04:21] <lifeless> or lazr_slony
[04:21] <StevenK> With a ., I hope
[04:21] <lifeless> nooo
[04:22] <lifeless> epic pain and suffering apply to namespaces
[04:22] <StevenK> lazr.restful, lazr.restfulclient ?
[04:22] <lifeless> terrible
[04:22] <lifeless> bugs open for years about import issues in their debs
[04:22] <lifeless> heinous tree layout to boot
[04:22] <StevenK> The _ offends me
[04:22] <StevenK> But fair point
[04:23] <rick_h_> it could be worse lazrPostgreSQL
[04:26] <StevenK> rick_h_: Don't make me send you to bed with no dinner.
[04:26] <rick_h_> heh, too late, had dinner, but I should go to bed
[04:27] <wgrant> lazr.restful* aren't as problematic as lazr.uri.
[04:27] <wgrant> But they're still not good.
[04:27] <StevenK> Sigh, 31degC makes me sad.
[04:27] <micahg> StevenK: beats 33degF
[04:27] <wgrant> Heh, it's like 14 down here.
[04:28] <wgrant> micahg: Cold is easy to solve. Heat is not.
[04:28] <StevenK> micahg: I'll take it
[04:28] <wgrant> while cold: apply clothing
[04:28] <wgrant> while hot: raise ImMelting()
[04:29]  * micahg has this magical thing called A/C
[04:29] <StevenK> Haha
[04:29] <StevenK> No A/C here, and no option for it.
[04:29] <rick_h_> what?!
[04:29] <StevenK> Rented apartment
[04:30] <rick_h_> A/C is why I went to college and got a good job. So i can just keep that running all summer and manage to pay the bill
[04:31] <jtv> StevenK: it's a bit over 32°C here, but turns out a fan helps.
[04:32] <jtv> Maybe that's just because it's winter here, but it feels nice & cool.
[04:33] <lifeless> jtv: you're in europe atm ?
[04:33] <jtv> Nope.
[04:34] <lifeless> ah, 'winter'
[04:34] <jtv> You caught me.  We don't _really_ have winter here.
[04:34] <StevenK> Australia has summer and lack-of-summer.
[04:35] <jtv> That's what I thought, until an Australian friend moved back there and emailed me a map, making me guess where he lived.
[04:36] <jtv> Thinking it was always hot in Australia, I said "what maniac called that place Sunnyvale?"
[04:36] <jtv> The answer: wow, you guessed our location!  We don't understand the name either — it's never sunny here.
[04:42] <spm> StevenK: one of my Uncles was in Mt Hagen in PNG for many many years. He said they had two seasons. The Wet Season, and the Wetter Season.
[04:43] <StevenK> Haha
[04:43] <spm> and canberra has all four seasons. so nyah.
[04:44] <huwshimi> spm: What, all the way from grey to misty?
[04:45] <spm> huwshimi: um. no. that's melbourne. you don't get grey and misty on 600mm average rainful.
[04:46] <huwshimi> spm: My first experience of Canberra involved not seeing the sun the whole time I was there.
[04:46] <spm> gees. my inlaws in mackay had one 24 hour period that copped more rain then we get in an average year.
[04:46] <huwshimi> spm: granted, it was only  a little over 24 hours :)
[04:47] <spm> huwshimi: heh, very unlucky then. a rubbish day here is when you can actually see a cloud in the sky. :-)
[04:47] <huwshimi> overnight bus, get in a 6am, misty, all day, misty, practice, misty, play gig at night, still misty, bus out at 4am
[04:47] <spm> ah yes. winter fogs. they can be special.
[04:48] <StevenK> spm: At $LAST_JOB, we found a part of southern NT that recieved 3000mm of rain.
[04:48] <StevenK> In 48 hours.
[04:48] <spm> although, the year before I moved here. they had a running joke. What do you call the day after two days of rain? Monday. Apparently it rained 12+ consecutive weekends.
[04:49] <spm> Ha!
[04:49] <spm> Tully would be the good one to check. in FNQ.
[04:49] <StevenK> A lake formed.
[05:19] <StevenK> PrivatePersonLinkageError: Cannot link person (name=team-name-100003, visibility=PRIVATE) to <TeamMembership at 0xfeb68d0> (name=None)
[05:19] <StevenK> ... so we can't have private subteams?
[05:19] <wgrant> Correct. That would make the team's membership opaque.
[05:20] <wgrant> In the current rules, the owner might not even be permitted to see that the member existed.
[05:20] <StevenK> Right, so there is no point testing for the private subteam case in terms of MixedVisibility?
[05:20] <wgrant> Not until we define and implement new rules.
[05:22] <StevenK> So according to lifeless, private superteams should not be disclosed
[05:22] <wgrant> Right, they're not important.
[05:23] <lifeless> StevenK: depends on the viewer :) But yes, not automatically disclosed.
[05:23] <StevenK> So I'm confused, since that is the major cause of MixedVisibilityError
[05:23] <wgrant> Those need to be hidden.
[05:24] <wgrant> When we allow private subteams, they must be shown.
[05:24] <wgrant> There's no reason to show private superteams to everyone.
[05:24] <wgrant> That benefits nobody.
[05:24] <StevenK> Right, so I should fix Person:+index to only return private superteams if the user is a member of the subteam?
[05:25] <wgrant> If the user has permission to view the subteam.
[05:25] <wgrant> Er
[05:25] <wgrant> To view the superteam.
[05:25] <StevenK> I'm just worried that is expensive.
[05:25] <wgrant> Which membership in the subteam would convey.
[05:25] <wgrant> But it's not the only way.
[05:25] <wgrant> Howso?
[05:25] <lifeless> StevenK: try:except: around it
[05:25] <wgrant> It's already shown as <hidden> because we know they don't have access.
[05:25] <wgrant> So we know whether they have access or not.
[05:26] <StevenK> But that's the TALES formatter, we aren't filtering the list
[05:26] <wgrant> That's irrelevant.
[05:26] <wgrant> We have the information.
[05:26] <wgrant> So we can filter on it.
[05:26] <StevenK> I'm just questioning the cost of calling checkPermission on each superteam
[05:26] <wgrant> Clearly it's fine, because we already do it.
[05:27] <StevenK> Oh, it's just done in the formatter.
[05:27] <wgrant> Otherwise we wouldn't know to raise the soft oops.
[05:27] <StevenK> Duh
[05:27] <StevenK> Obviously, my brain is made out of silicon.
[05:31] <StevenK> Ewww, Person.select()
[05:44] <lifeless> argggh
[05:44] <lifeless> stuck ec2 instance
[05:44] <lifeless> 500dollar ec2 bill
[05:45] <nigelb> wow
[05:45] <StevenK> WIN
[05:45] <wgrant> ow
[05:45] <nigelb> Extra Large instance?
[05:45] <nigelb> Wait, how long was it stuck?
[05:45] <lifeless> $0.68 per High-CPU Extra Large Instance (c1.xlarge) instance-hour (or partial hour) 729 Hrs 495.72
[05:46] <nigelb> wait, it remained stuck for 729 hours?...
[05:46] <lifeless> apparently
[05:46] <StevenK> No, that can't be right
[05:46] <StevenK> Probably a few weeks, plus other usage
[05:46] <lifeless> a whole month, yes.
[05:46] <StevenK> Since a month is only 730 hours.
[05:46] <nigelb> Oh another note.
[05:47] <nigelb> If you use 1.5 hours, amazon chargse for 2 hours. (assuming the instance is killed after that)
[05:47] <lifeless> we setup the teardown after it sets up
[05:47] <lifeless> no, one instance, I'm pretty sure
[05:47] <lifeless> my net has been shite
[05:47] <StevenK> You don't use ec2 for anything else?
[05:47] <lifeless> so I suspect a ec2 instance was kicked off and never had the shutdown timeout called
[05:47] <lifeless> StevenK: no
[05:47] <StevenK> Ah
[05:47] <lifeless> StevenK: or rather, yes, I don't use it for anything else.
[05:48] <nigelb> Well, lessson learnt at least :)
[05:48] <StevenK> It is well known that lifeless' Internet is crap.
[05:48] <nigelb> Maybe someone should check how many instances are around at any time and when it was procurred.
[05:48] <lifeless> what lesson? don't use 'ec2 land' ?
[05:48] <nigelb> hah
[05:49] <nigelb> like a status page showing all currently running instances and when it was taken, should help track it down better.
[05:49] <StevenK> lifeless: rvb has a cronjob that checks ec2 ls
[05:49] <huwshimi> lifeless: Will stuck instances show up with 'ec2 list'
[05:49] <StevenK> nigelb: We have that, 'bin/ec2 ls'
[05:49] <lifeless> huwshimi: if you think to run it, yes
[05:49] <nigelb> ahh
[05:49] <wgrant> They show up in the numbers at the bottom.
[05:49] <huwshimi> lifeless: Haha, ok :)
[05:49] <wgrant> They don't necessarily show up in the list, however.
[05:49] <lifeless> I normally have a widget - aws-status - that shows all my instances
[05:49] <lifeless> however, it hasn't been updated to indicators
[05:50] <lifeless> so I don't have it anymore
[05:50] <nigelb> StevenK: heh, I got very excited and tried it out :P
[05:50] <nigelb> and realized I don't have access ;)
[05:51] <wgrant> You do have access :)
[05:51] <StevenK> I think you can have access, you just have to pay for it
[05:51] <nigelb> hah.
[05:52] <nigelb> Oh, you guys use your own accounts and then expense it?
[05:52] <wgrant> Yep
[05:52] <StevenK> Right
[05:53] <nigelb> AHHHH
[05:53] <nigelb> ok, that makes sense. I thoguht y'all were sharing one account.
[05:53] <StevenK> So if you run ec2 test twice a month it should cost you about $5.50
[05:53] <nigelb> (that's what we do at work)
[05:54] <nigelb> We have one account which is paid by corporate card and 3 of us get the keys to that
[06:08] <spm> o/ nigelb
[06:20] <nigelb> Hey spm :)
[06:50] <StevenK> lifeless: I can't find the mail again, but I find newest first for mailman to be *backward* from every other mailman instance I play with.
[06:56] <lifeless> I agree
[06:56] <lifeless> as wgrant says thats not a good reason to do/not do something
[06:56] <lifeless> but newest first is just terribly slow the way things are structured today
[06:57] <StevenK> lifeless: It just gives me pause to think when looking. Since it performs like a utter dog too, I say change it.
[07:03] <wgrant> Oldest-first would work if we didn't have a single archive for all-time.
[07:03] <wgrant> s/would work/might be acceptable/
[07:03] <StevenK> Right
[07:26] <huwshimi> So, how do we upgrade our version of cssutils?
[07:26] <huwshimi> The current version can't handle some css3 syntaxes
[07:27] <wgrant> We're currently using 0.9.66
[07:27] <wgrant> Er
[07:27] <wgrant> 0.9.6
[07:27] <wgrant> See versions.cfg
[07:28] <huwshimi> wgrant: Yup and there's a (stable) version 0.9.7 that supports what I need
[07:29] <wgrant> huwshimi: Grab a tarball, add it to download-cache alongside the old one, update versions.cfg.
[07:35] <huwshimi> wgrant: Where does our config look to grab stuff from?
[07:35] <huwshimi> wgrant: pypi?
[07:35] <wgrant> huwshimi: No, it doesn't look online. It looks in download-cache/dist
[07:36] <wgrant> You'll see lots of eggs and tarballs in there.
[07:36] <huwshimi> wgrant: Oh right, so I need to commit a new tarball?
[07:36] <wgrant> huwshimi: Right.
[07:36] <huwshimi> ah
[07:36] <wgrant> huwshimi: There's no PQM/reviews for that branch. You can commit/push directly.
[07:37] <huwshimi> wgrant: But I need to push the change to lp for the versions.cfg change though right?
[07:37] <wgrant> Right.
[07:42] <huwshimi> wgrant: Do I need to do anything else to make launchpad start using the new version?
[07:43] <huwshimi> wgrant: Do I need to get it to build a new egg or something
[07:43] <wgrant> huwshimi: No. buildout will automatically create the egg from the tarball once you update versions.cfg
[07:43] <huwshimi> wgrant: Oh, I guess I better run buildout :)
[07:43] <huwshimi> oops, thanks :)
[07:45] <wgrant> Ah, I see, yes.
[07:47] <huwshimi> Oh, I guess it would help if I changed the versions.cfg of the branch I was using too
[08:12] <huwshimi> Does anyone know how to enable the beta banner for a page locally?
[08:54] <mrevell> Hi
[09:07] <adeuring> good morning
[12:20] <gmb> Oh, hey, leaving a partial DB patch lying around will break things. Who'da thunk?
[12:23] <nigelb> stub: You might enjoy this - http://thedailywtf.com/Articles/Directive-595.aspx
[13:03] <rick_h_> morning
[14:24] <abentley> rick_h_: The updated spinner looks good to me.
[14:24] <rick_h_> abentley: ok cool, Since deryck is going to be here soon I'll want to sanity check with him and if that works then will submit for review/land
[14:24] <rick_h_> /want/wait
[14:25] <abentley> rick_h_: cool.
[14:25] <rick_h_> abentley: did you see the emails with huw from last night? Are we supposed to be jumping to the top of the page on next/prev?
[14:26] <abentley> rick_h_: Yes.  In an email today, I explained that deryck was going to do that, but I don't think it should be associated with the spinner, just updating the batch.
[14:27] <rick_h_> abentley: right, ok.
[14:35] <abentley> bac: would you consider re-reviewing https://code.launchpad.net/~abentley/launchpad/person-bug-listings/+merge/83860?  I've made an important change.
[14:36] <bac> abentley: ok
[14:36] <abentley> bac: Thanks.  The change is that the view_name is now provided by LP and used by the javascript.
[14:44] <bac> abentley: it looks good but i have to wonder if there isn't a better way to get the viewname?  i don't have any bright ideas but what you've done feels kludgy.
[14:46] <dobey> jelmer: were you going to add me to ~vcs-imports?
[14:47] <jelmer> hi dobey
[14:47] <jelmer> dobey: sorry, I hadn't understood that you actually wanted to be in ~vcs-imports. One sec, I'll add you.
[14:47] <abentley> bac: I don't know of a better way to get the view name.  I believe using getGlobalSiteManager().registeredAdapters() was gary_poster's suggestion.
[14:47] <dobey> jelmer: oh sorry. yes please. thanks :)
[14:47] <bac> abentley: ok
[14:47] <jelmer> dobey: welcome :)
[14:49] <bac> abentley: done.
[15:13] <benji> Hey guys, I'm working with the LOSAs to get a small DB permission change for a script to fix a critical regression; in an email stub said that I "need someone to manually apply the permissions to production" but neither I nor the LOSA know what exactly that means.  He asks if "running ./security.py wouldn't work?"  Hints?
[15:25] <deryck> abentley, adeuring -- standup in 4 ok?
[15:26] <abentley> deryck: sure.
[15:26] <adeuring> deryck: sure
[15:26] <deryck> cool
[15:42] <bac> hi jelmer
[15:42] <jelmer> hi bac
[16:12] <benji> flacoste: I am in need of someone I can ask a DB deployment question.
[16:17] <flacoste> benji: shoot!
[16:18] <flacoste> i'll do my best to answer
[16:18] <benji> flacoste: I'm working with the LOSAs to get a small DB permission change for a script to fix a critical regression; in an email stub said that I "need someone to manually apply the permissions to production" but neither I nor the LOSA know what exactly that means.  He asks if "running ./security.py wouldn't work?"
[16:19] <flacoste> benji: yes, if we run it as we do as part of nodowntime, that should do the trick
[16:19] <benji> flacoste: thanks
[17:11] <gmb> sinzui: I have a question about bug 894390, if you've got a second.
[17:11] <_mup_> Bug #894390: It's possible for Person.account and EmailAddress.account to be different for the same person <db> <merge-deactivate> <openid> <users> <Launchpad itself:In Progress by gmb> < https://launchpad.net/bugs/894390 >
[17:12] <sinzui> I do
[17:15] <gmb> sinzui: Okay. Quickly put, then: Will anything really bad happen if we move the code that changes email.account and email.person out of MergePeopleView._doMerge() and into the job code?
[17:15] <gmb> I realise that we're then deferring the check for other email addresses on the dupe account
[17:15] <sinzui> quick answer nothing bad
[17:16] <sinzui> gmb, I wanted to do it
[17:16] <gmb> But at the moment that check / change is preventing me from putting in a simple constraint to ensure that Person.account and EmailAddress.account point to the same place.
[17:16] <sinzui> I think it is a bit tricky because of timing and rules checks
[17:17] <gmb> Yeah.
[17:18] <sinzui> gmb, that view code is using the removeSecurityProxy too? I think we really do want that code in the model level
[17:18] <gmb> sinzui: Yup, I thought that too :)
[17:18] <gmb> sinzui: Are we only caring about the user in doing the check in the view? I.e. do we mostly care that they get told if the merge can't happen?
[17:18] <gmb> (Because we could conceivably do all that in a rabbity fashion, hand-wave, etcetera)
[17:20] <sinzui> gmb: yes. We really want the user to know that they are done confirming *many* email addresses. The code is counting down to 0
[17:20] <sinzui> Then we tell the user we are going to do it
[17:20] <gmb> Hrrrm.
[17:20] <sinzui> We can count down to 1 maybe
[17:22] <gmb> Hmm, possibly.
[17:23] <gmb> sinzui: Actually, if we did the check for emailset.getByPerson(self.dupe).count() > 1 (or whatever) early on in _doMerge(), wouldn't it have a similar effect?
[17:23] <gmb> Oh, no.
[17:23] <gmb> Bother.
[17:23] <gmb> That doesn't actually solve the problem *at all*
[17:40] <deryck> lunch time for rick_h_ and I.
[18:45] <sinzui> abentley, Do you have time to review https://code.launchpad.net/~sinzui/launchpad/dsp-vocab-unknown-distro
[18:46] <abentley> sinzui: I can get to it in a bit.
[19:10] <abentley> sinzui: Is it intentional that test_getInputValue_package_spn_dsp_picker_feature_flag and test_getInputValue_package_dsp_dsp_picker_feature_flag have identical comments?
[19:11] <sinzui> no :(
[19:15] <abentley> sinzui: around 171 and 187, I think you can simplify getUserBrowser().open(canonical_url(bug)) to getViewBrowser(bug)
[19:15] <sinzui> I certainly an
[19:16] <sinzui> can
[19:17] <abentley> sinzui: technically, test_setDistribution should have a comment, though I don't know what I'd say.
[19:18] <abentley> sinzui: And there should be a docstring on setDistribution itself.
[19:19] <sinzui> I would say it permits the callsite to set the vocab's distribution after the vocab was instantiated by another mechanism
[19:20] <abentley> sinzui: Okay,  r=me with those text changes.
[19:20] <sinzui> thank you
[19:21] <abentley> sinzui: Could you review one for me?
[19:21] <sinzui> yes I can
[19:22] <abentley> sinzui: https://code.launchpad.net/~abentley/launchpad/history-model-fix/+merge/83995
[19:23] <abentley> sinzui: I can provide some context if you like.
[19:23] <sinzui> Does this fix my back button? I sometimes need to go back twice to go back one page?
[19:24] <abentley> sinzui: On the new bug listings?
[19:24] <sinzui> yes
[19:24] <abentley> sinzui: It's not a bug I've observed, but I think it might fix that.
[19:26] <sinzui> abentley, lint lists 6 files, the diff shows 1
[19:26] <abentley> sinzui: I don't think lint takes prerequisite branches into account.
[19:26] <sinzui> ahh there is a preqeq
[19:27] <sinzui> r=me
[19:27] <abentley> sinzui: thanks!
[19:35] <lifeless> sinzui: hi
[19:35] <lifeless> sinzui: mailman
[19:37] <sinzui> yes mailman
[19:37] <sinzui> never postwoman
[19:37] <lifeless> is it easy to turn on monthly indexes vs all-time ?
[19:38] <sinzui> lifeless, I think it is the same work as what I described in my reply to your email. I am not familiar with the switch/flags in the file, but I think it is simple to add and a few days to generate
[19:38] <lifeless> coooool
[19:39] <lifeless> do you feel like doing it yourself?
[19:39] <lifeless> cause, you have like +10000 from me if you want to
[19:40] <sinzui> I will consider it for Friday. I have committed to fixing the so-called "bug supervisor" label on the advanced bug search form for Friday morning
[19:40] <lifeless> \o/
[19:42] <lifeless> sinzui: separately
[19:43] <lifeless> sinzui: wallyworld_ asked me yesterday about disclosing team names on branch pages; I said my understanding was that was fine as long as we'd cleaned up existing subscriptions to remove teams that don't want to be disclosed
[19:43] <lifeless> this turned into a discussion about whether that was work we'd decided to do or not, or something
[19:43] <lifeless> 16:25 < lifeless> my understanding is that we settled on 'when the team interacts with something' and 'team interactions will prompt to permit the interaction'
[19:44] <lifeless> 16:25 < lifeless> its the second bit I suspect is missing
[19:44] <lifeless> 16:25 < wallyworld_> yes
[19:44] <lifeless> 16:26 < wgrant> The second bit requires an API break.
[19:44] <lifeless> 16:26 < wgrant> In dozens of places.
[19:44] <lifeless> 16:26 < wallyworld_> maybe we decided against it then. i can't recall
[19:44] <lifeless> 16:27 < lifeless> I'd worry a little if we had
[19:44] <lifeless> 16:28 < lifeless> because we have a number of policies intended to prevent accidental discovery of private team names
[19:44] <lifeless> 16:28 < lifeless> and not doing the second bit will deeply devalue them
[19:44] <lifeless> 16:28 < wallyworld_> my memory is fuzzy, so i'm not sure one way or the other
[19:44] <lifeless> 16:28 < wgrant> I thought we were going to skip that, because of the enormous and ever-expanding scope creep it would entail.
[19:44] <lifeless> 16:29 < wgrant> Given recent happenings, I don't think we need any more of that...
[19:44] <lifeless> 16:29 < wallyworld_> i seem to recall that the discussion was that private team names could be exposed
[19:44] <lifeless> 16:29 < wallyworld_> and that people would have to given them cryptic names
[19:44] <lifeless> 16:29 < wallyworld_> if they didn;t want others to guess things
[19:44] <lifeless> 16:32 -!- timrc [~tim@99-57-130-76.lightspeed.austtx.sbcglobal.net] has joined #launchpad-dev
[19:44] <lifeless> 16:34 < lifeless> noone told me :)
[19:44] <lifeless> 16:35 < wgrant> We don't have a compelling, pretty, feasible private team design.
[19:44] <lifeless> 16:35 < wgrant> We no longer have a compelling, pretty, feasible private artifact design.
[19:44] <lifeless> 16:36 < wallyworld_> lifeless: perhaps we can all have a chat with sinzui tomorrow to clear it up. in case i/we have misunderstood anything
[19:44] <lifeless> -fin
[19:46] <sinzui> I think my team was slowly understanding what I meant by traversal. wallyworld_ did produce a branch that seem to do the right thing to check if a user may access a subordinate object
[19:46] <sinzui> we have not solved the important case yet to say we really know how to do this...eg stop avoiding the private team p3a subscription problem
[19:47] <lifeless> anyhow, I believe you have a standup. Perhaps I can join at the end of that and we can have a brief chat? I don't want to be adding confusion to your team when they ask me things :)
[19:47] <sinzui> lifeless, We do not yet know how to present pages when the user as restricted access
[19:47] <sinzui> okay
[19:51] <sinzui> lifeless, https://code.launchpad.net/~wallyworld/launchpad/view-private-branch-artifacts-605130/+merge/83915 shows the draft that wallyworld_ took after discovering the bug was about traversal
[19:55] <timrc> Not that I'm going to add anything of value here, but most of our (Commercial Engineering)  privacy needs could be met if running own instance of Launchpad were more feasible
[19:55] <timrc> let the firewall naturally provide most of the security for us
[19:56] <timrc> doesn't solve the problem of privacy for external customers though (unless they too ran their own instances of Launchpad)
[19:57] <lifeless> timrc: AIUI thats bogus :)
[19:57] <lifeless> timrc: because you have multiple vendors you collaborate with, and you don't want mutual-disclosure amongst them
[19:58] <timrc> if we could bring up separate launchpad instances for each, though?
[19:58] <timrc> that would imply Launchpad were much lighter than it is today, though
[19:58] <lifeless> it would be a totally different thing at that point
[20:06] <timrc> there has been customer interest to put image building behind the firewall but what of the archive? on the face of things launchpad seems perfectly suited for that, but in practice, that would be a nightmare
[20:06] <flacoste> more like a set of bugzilla instances :-)
[20:06] <flacoste> which means, no collaboration between them
[20:06] <flacoste> which isn't what LP is about
[20:09] <timrc> flacoste, how do private projects within launchpad.net collaborate today?
[20:10] <flacoste> timrc: well they use multiple bug tasks
[20:10] <timrc> I thought that was going away :)
[20:10] <flacoste> you asked today?
[20:10] <timrc> lol ok
[20:10] <flacoste> but you are right
[20:10] <timrc> fair enough
[20:10] <flacoste> that's changing to use linking between issues
[20:10] <flacoste> so that it's easier to manage the conversations
[20:11] <flacoste> and easier to understand who has access to what
[20:11] <flacoste> but linked issues will still make it easier to collaborate than setting separate bugzilla instances
[20:11] <flacoste> which really never talk to each other
[20:11] <flacoste> as a back story
[20:11] <flacoste> Canonical and Ubuntu started by using bugzilla itself
[20:12] <flacoste> and then quickly saw that trying to talk to upstream would never scale with it
[20:12] <flacoste> and that's when LP was born
[20:12] <timrc> Federate your Launchpad instances so BigCo's launchpad instance is comprised of all the data from launchpad.net and launchpad.bigco.com
[20:12] <flacoste> well, its bug tracker at least
[20:12] <flacoste> timrc: yep, that would be another way of doing it
[20:12] <flacoste> but more work
[20:12] <flacoste> and you guys have waited long enough already ;-)
[20:13] <timrc> lol
[20:14] <lifeless> federation has the same issues FWIW
[20:15] <lifeless> 'if I reply to this bug, who sees the response'
[20:15] <lifeless> 'who is this bug accessible to'
[20:15] <lifeless> 'who should control accessibility to this bug'
[20:15] <timrc> depends on where the bug originates?
[20:15] <lifeless> sure
[20:15] <timrc> if the bug originates on launchpad.bigco.com than by default it's only visible to people with access to launchpad.bigco.com
[20:15] <lifeless> but if you get notified on bugs that are just federated in
[20:16] <lifeless> and you reply with proprietary info because you are confused...
[20:16] <abentley> deryck: chat?
[20:17] <deryck> abentley, deep in sprinting right now.
[20:17] <abentley> deryck: okay.
[20:17] <deryck> abentley, is this about something you're hacking on?
[20:17] <abentley> deryck: Yes.
[20:17] <timrc> lifeless, we have a nice banner that says "this bug is private"... I can envision the same here
[20:17] <lifeless> timrc: right, but you see that its not something improved by federating
[20:18] <deryck> abentley, is this something you need me for, or could someone else pre-imp you?
[20:18] <lifeless> timrc: federating doesn't naturally solve it
[20:18] <timrc> lifeless, it seems more intuitive, the separation seems clearer
[20:19] <abentley> deryck: I wanted some policy direction, but I think I can get started without it.
[20:19] <timrc> you don't set a privacy bit, it's implied by organizational structure
[20:19] <lifeless> I think federating is a good way to think about the problem
[20:20] <lifeless> but I don't think the act of federating itself solves much, not if you have it all automated
[20:21] <deryck> abentley, ok, cool.  Thanks!
[20:25] <timrc> okay, well thanks for humoring me :) i know your time is precious
[20:26] <timrc> I am trying to find a critical bug I can work on in my spare time -- need you guys focused on privacy! ;)
[20:29] <jcsackett> abentley: free for a review? https://code.launchpad.net/~jcsackett/launchpad/fancy-filebug-part2/+merge/84004
[20:31] <abentley> jcsackett: I don't understand the difference between a private bug and a private-by-default bug.
[20:32] <abentley> jcsackett: Do you know why these ribbons are implemented in JavaScript?
[20:35] <jcsackett> abentley: private by default is projects where all reported bugs are automatically marked as private.
[20:36] <abentley> jcsackett: I got confused because I didn't understand were were talking about a bug that doesn't exist yet.
[20:36] <jcsackett> abentley: ah, yes, this is on +filebug, so as you're reporting it.
[20:36] <jcsackett> sorry if my mp didn't make that clear.
[20:37] <jcsackett> as to the javascript, abentley, it was written originally for existing bugs, so that it would dynamically display when a bug was marked as private or public once it already existed.
[20:37] <jcsackett> it seemed better to just reuse that even in non-dynamic situations then create another display.
[20:37] <jcsackett> and in the case of toggling the security related stuff, the dynamic part is actually desireable.
[20:38] <abentley> jcsackett: It just seems bad not to provide these ribbons to non-JS users.
[20:39] <abentley> jcsackett: Our new beta banner was based on these ones, so I've filed Bug 891697 about it.
[20:39] <_mup_> Bug #891697: Beta banner is not shown if JavaScript is disabled. <Launchpad itself:Triaged> < https://launchpad.net/bugs/891697 >
[20:40] <jcsackett> abentley: that's fair.
[20:40] <jcsackett> abentley: i *believe* the old privacy display (the grey stripey edging) still shows when you're looking at a private bug if you don't have JS.
[20:40] <jcsackett> but having something like the banner still work would be better.
[20:40] <abentley> jcsackett: oh, that's good.
[20:41]  * timrc tests that
[20:43] <abentley> r=me.  I prefer "set up" rather than "setup" for the verb, but I guess both are used.
[20:43] <timrc> jcsackett, it does indeed show the grey stripey edge
[20:43] <jcsackett> abentley: thanks. i've updated your bug to explicitly include the privacy banner, b/c the same considerations apply.
[20:55] <poolie> hi all
[21:09] <sinzui> abentley, I share your observation about the privacy banner. It was interactive. We removed the hide button, so it is just structure and CSS now. in fact, we still load the old css. you will see the old background stripe on the left when the page loads :(
[21:14] <lifeless> thats good if js is disabled ;)
[21:21] <flacoste> sinzui: timrc disabled js and confirmed that the old background strip appears
[21:22] <flacoste> hi poolie
[21:22] <poolie> hi there
[21:22] <flacoste> benji: are we ready to renable the translations jobs?
[21:23] <flacoste> benji: a user complained again on #launchpad
[21:23] <sinzui> lifeless, flacoste it is not good, it is only acceptable. The page could have used the pretty CSS by default!
[21:23] <benji> flacoste: we are (well, they weren't jobs before, but now are)
[21:23] <flacoste> sinzui: right
[21:24] <flacoste> benji: care to file a RT for it? I'll put it at the top of the queue
[21:24] <timrc> gray stripey edge is definitely subtle
[21:24] <benji> flacoste: the only problem remains that there is a disagreement about how exactly that is done, or if anything needs to be done at all
[21:24] <flacoste> benji: what's the disagreement about?
[21:24] <timrc> I've grown to depend on the red bar to make sure I'm not about to do something regrettable
[21:24] <timrc> if only I had it for other aspects of my life
[21:25] <benji> flacoste: I wasn't around when it was last discussed but the way it was communicated to me was that nothing needed to be done and the jobs would simply begin running
[21:25] <flacoste> benji: i doubt that
[21:25] <benji> flacoste: you and me both :)
[21:25] <flacoste> benji: right, we need a new cron job
[21:25] <flacoste> there is a generic script to run these jobs
[21:26] <flacoste> but the arguments to the script are job-specific
[21:26] <flacoste> iow, the config section to use
[21:26] <benji> right (cronscripts/run_jobs.py)
[21:27] <benji> flacoste: I'll file an RT to add "cronscripts/run_jobs.py pofile_stats" to the crontab or equivalent.
[21:28] <flacoste> benji: thx, let me know the # so that i can adjust the priority
[21:28] <benji> flacoste: will do
[21:34] <benji> flacoste: RT #49635
[21:34] <_mup_> Bug #49635: adept is _really_ slow.  <adept (Ubuntu):Fix Released by mornfall> < https://launchpad.net/bugs/49635 >
[21:37] <flacoste> benji: thx
[21:37] <benji> np
[21:41] <lifeless> sinzui: so what time is the clal ?
[21:42] <sinzui> 19 minutes
[21:42] <sinzui> we use mumble
[21:42] <lifeless> kk
[21:42] <sinzui> I suspect we are the last team to use mumble
[21:44] <poolie> o/ sinzui
[21:47] <sinzui> poolie, Last year, I had mumble on all the time and talked many times a day. Used mumble about 7 time a week now. :(
[21:47] <poolie> that is more often than me
[21:47] <poolie> if i had better audio hardware
[21:47] <poolie> i would use it more
[21:47] <poolie> not sure what that would look like though
[21:49] <lifeless> if it worked better in .nz I would use it more ;)
[21:54] <beuno> sinzui, in U1 we only use mumble, a lot of us are on it for the full working day and move between rooms to talk to people
[21:55] <sinzui> beuno, That is what I remember the ~launchpad team was doing 12 months ago
[21:58] <mwhudson> lifeless: it's been fine for me lately
[21:58] <mwhudson> of course i have super internet in the office
[21:58] <mwhudson> (by nz standards)
[21:59] <lifeless> beuno: I can't work like that - too much distractions (see for instance the research into productivity losses in open plan offices)
[22:00] <beuno> lifeless, right, so my work is basically interrupt-based, so if anyone is blocked on something, they can just jump in and talk
[22:00] <beuno> when I need to focus, I close it
[22:01] <lifeless> beuno: they can do that to me too; but when its not happening I am focused ;)
[22:01] <beuno> lifeless, it's a bigger barrier if you need to ping someone on irc, get them to log in, adjust their mic, etc etc etc
[22:02] <beuno> if I'm already there, it's cheap and quick
[22:02] <abentley> sinzui: We never really did that on the Code team.
[22:02] <lifeless> beuno: perhaps
[22:02] <beuno> lifeless, then we also have a policy where developers always work in pairs, so they have their own channels
[22:02] <beuno> I can get dragged into those
[22:03] <beuno> or other developers can get pinged to join them
[22:03] <beuno> it's been quite good for us
[22:03] <beuno> OTOH, when it's hammer time, people even drop off of IRC   :)
[23:18] <sinzui> StevenK, bug 603732
[23:19] <_mup_> Bug #603732: If there is no driver a maintainer should be able to accept a bug nomination <bugnominations> <lp-bugs> <planning> <series> <Launchpad itself:Triaged> < https://launchpad.net/bugs/603732 >
[23:33] <sinzui> wallyworld_, Do you want to talk about launchpad.LimitedView on mumble
[23:34] <wallyworld_> sinzui: ack
[23:42] <poolie> is it just me who sees ec2 host keys getting cached in my real keyring by ec2test?