[00:17] <StevenK> wallyworld_: O hai
[00:17] <wallyworld_> hello
[00:17] <wallyworld_> did we need to mumble?
[00:17]  * StevenK looks for mumble
[00:44] <StevenK> wgrant: How is the second branch wrong? I don't want to set it to private if it's EMBARGOEDSECURITY for the moment.
[00:47] <wgrant> StevenK: In commands.py?
[00:47] <StevenK> wgrant: Yup.
[00:47] <wgrant> StevenK: It will currently AssertionError if given EMBARGOEDSECURITY
[00:48] <StevenK> Oh, I fixed that, just forgot to commit and push.
[00:55] <poolie> wgrant, hi
[01:18] <wgrant> poolie: Hi
[01:24] <StevenK> wgrant: I removed the assert, I'm going to toss it at ec2.
[01:25] <StevenK> wgrant: As to why createBug() is in systemhomes, I still have NFI
[02:05] <lifeless> wgrant: got 5 for a quick chat ?
[02:40] <wgrant> lifeless: Just got back from lunch. Still around?
[02:43] <lifeless> yes
[02:43] <lifeless> skype?
[02:43] <wgrant> It hates PulseAudio. Let me see.
[02:44] <lifeless> pavucontrol will let you fix that easily
[02:44] <wgrant> No, it won't even connect to PA AFAICT
[02:44] <lifeless> oh, thats new and special
[02:44] <wgrant> Yeah
[02:44] <wgrant> Haven't had this one before.
[02:44] <wgrant> Let's see if the one from partner works.
[03:21] <mwhudson> PA seems to have decided my headset is not an input device recently
[03:23] <bigjools> it would be right? :)
[04:25] <StevenK> Hmm, how do I tell firebug to keep executing JS?
[04:26] <StevenK> The play button. Tricky.
[07:41] <adeuring> good morning
[09:01] <StevenK> cjwatson: Are you good to QA r15036 on DF today?
[10:59] <cjwatson> StevenK: yep, I will be
[11:18] <stub> wgrant: If your still there, does PG 9.1 make your life easier with bugtask search data structures? Things are so far on track to switch Production starting 23rd April.
[11:18] <stub> (Minor things like the Precise release might affect that :) )
[11:21] <stub> This merge proposal is making me thirsty.
[11:25] <wgrant> stub: Being able to use GIN for a second iteration will be nice.
[11:25] <stub> Saw your comment about array syntax mentioning 8.4
[11:26] <wgrant> And its better support for text arrays might open up new avenues for tags.
[11:26] <stub> But it isn't worth doing this as a 9.1 specific feature branch?
[11:27] <wgrant> No. This is good enough for now, and we get it a month early.
[11:27] <wgrant> Anything 9.1-specific will need more experimentation post-upgrade.
[11:27] <wgrant> And this is deliberately designed so we can iterate cheaply by introducing new versions of the table.
[11:28] <StevenK> I'm looking forward to the death of slony. Oh, and 5 seconds FDT.
[11:34] <stub> wgrant: What do the indexes ending with the bugtask or bug columns get used for. Is it being used as a creation date (but with stable ordering)?
[11:35]  * stub reads the mp blurb just in case this was explained :)
[11:35] <wgrant> stub: Ah, sorry, forgot about the indices.
[11:35] <wgrant> stub: Those are bug search sort orders.
[11:35] <wgrant> So bugtask/bug are tiebreakers.
[11:36] <stub> Just to ensure consistent ordering?
[11:36] <wgrant> bug is used when the context is unambiguous (only a single task for each bug can appear, ie. most contexts), bugtask when it's ambiguous (eg. distributions, where you can have tasks for multiple packages on a single bug)
[11:36] <wgrant> Yes, I believe.
[11:36] <wgrant> And to make it logical.
[11:36] <wgrant> eg. ordering by importance, the first 200000 bugs or so are a single importance.
[11:36] <wgrant> And having them arbitrarily ordered would be odd.
[11:36] <wgrant> Those indices are just a start, but they satisfy all the common bug search cases.
[11:36] <stub> But no need to pull in product.name and friends
[11:37] <wgrant> We may eventually want something more selective on status, duplicateof, etc.
[11:37] <wgrant> No.
[11:37] <StevenK> Is this the review of bugtaskflat?
[11:37] <wgrant> There are some orders that I'm probably going to ban on large sets of bugs.
[11:37] <wgrant> Assignee name, tag, location name, etc.
[11:37] <wgrant> They're not useful, and very expensive on large sets.
[11:38] <wgrant> And for small sets it's fine to do the sort as the last stage.
[11:38] <stub> I think we should consider telling the user they are being nonsensical if the query results are nonsensical. If the first 200000 bugs are a single importance, the answer isn't important because it is rather useless.
[11:38] <wgrant> stub: Indeed.
[11:38] <wgrant> stub: But that's the default sort order :)
[11:38] <stub> Yes, the principal remains :)
[11:39] <wgrant> stub: Half these indices are to satisfy eg. https://launchpad.net/launchpad/+bugs
[11:39] <stub> Just wrapping my head around what we have here
[11:39] <stub> StevenK: Yes
[11:39] <wgrant> With just a straight walk down the index.
[11:39] <wgrant> In 2-3ms.
[11:39] <wgrant> Person:+bugs is going to be interesting. It's not clear what indices are best there.
[11:40] <wgrant> Fortunately we have feature flags to disable BugTaskFlat use where it doesn't work yet :)
[11:40] <wgrant> s/doesn't work yet/turns out to be slow sometimes without further indices/
[11:41] <wgrant> The indices *will* need further work, but this seems to be a good start for most things.
[11:42] <stub> wgrant: So Celery can use PostgreSQL as a backend. Perhaps these triggers should just launch Celery jobs :-)
[11:43] <wgrant> These are about 100x faster than bugsummary in some cases, and I am rewriting bugsummary to be less insane, so it will be a net speedup :)
[11:46]  * cjwatson would love review of https://code.launchpad.net/~cjwatson/launchpad/proposed-as-staging-pocket/+merge/99911
[11:49] <cjwatson> Anyone mind if I upgrade mawson?
[11:53] <wgrant> cjwatson: Go ahead.
[11:53] <wgrant> Hopefully the DB upgrade won't break.
[11:54] <cjwatson> Anything I need to watch out for in particular?  Or is this the stuff that's been afflicting NDTs?
[11:54] <wgrant> Nah, just mawson sometimes misses some of the migrations.
[11:54] <wgrant> And occasionally gets manual BugTaskFlat patches that could conflict.
[11:54] <wgrant> But I think it should be OK
[11:54] <wgrant> If it breaks, yell and I'll fix.
[11:55] <cjwatson> running
[11:55] <StevenK> cjwatson: Only if you happen to 'upgrade' to something that's 100 revisions behind.
[11:55] <wgrant> 150, TYVM
[11:55] <StevenK> Indeed.
[11:55] <StevenK> That was a fun morning.
[11:55] <cjwatson> How did that happen?
[11:56] <StevenK> cjwatson: Worse, it was on prod.
[11:56] <wgrant> 'tis a mystery
[11:56] <StevenK> And we're in the middle of two rather large migrations for disclosure.
[11:56] <cjwatson> hmm, Text conflict in lib/lp/scripts/garbo.py
[11:56] <wgrant> bzr resolve --take-other
[11:56] <wgrant> That's from when I was manually running a single garbo job to complete a migraiton
[11:59] <cjwatson> mkay
[11:59] <cjwatson> mawson's bzr is too old for resolve --take-other, I used revert instead, hope that was ok
[12:00] <wgrant> Yeah, that's fine.
[12:09] <wgrant> cjwatson: You win the award for lowest SNR in a Launchpad merge proposal, but approved :)
[12:13] <cjwatson> wgrant: I assumed everyone else's merges were like that nowadays too as they desperately scrabbled for LoC.  Maybe not
[12:14] <wgrant> cjwatson: We tend to split branches when the get like that. It's not a strict rule that every *branch* must not be LOC-positive.
[12:15] <cjwatson> OK, I'll try to remember that.  I guess I find it hard to keep track otherwise
[12:16] <wgrant> cjwatson: Indeed, that's the problem :)
[12:16] <wgrant> cjwatson: Can you set a commit message?
[12:16] <cjwatson> done
[12:16] <cjwatson> Ah, mawson at least thinks it's done now.
[12:32] <cjwatson> http://people.canonical.com/~cjwatson/tmp/loc.png - I was curious what LoC delta per revision actually looks like since the new policy ...
[12:33] <cjwatson> different view from ohloh's
[12:36] <wgrant> I've been meaning to get around to repurposing community-contributions.py to provide some kind of analysis like that.
[12:38] <cjwatson> net +1901 since new policy
[12:40] <cjwatson> which is not really obvious from that graph
[13:04] <bac> so, perhaps we should limit the length of a bug report title:  pad.lv/943974
[13:07] <rick_h> hah, that's great.
[13:07] <stub> I think the limit in the db is 2GB
[13:26] <nigelb> wtf
[13:26] <nigelb> that is a big title.
[14:29] <deryck> I'd be happy to help get another deploy today, but I must admit I have no clue how to qa cjwatson's changes.
[14:30] <deryck> I think all of our soyuz experts are australian now, too.  hmmmm
[14:30] <cjwatson> deryck: I just finished QAing it.
[14:31] <deryck> cjwatson, ah very good!  Thanks, man.
[14:32] <deryck> adeuring, now we're just waiting on your revision.
[14:32] <cjwatson> I'd like that deployed on ftpmaster at some point; I don't know what the deployment procedures for that look like these days.
[14:32] <adeuring> deryck: argh, got distracted...
[14:33] <deryck> adeuring, np. :)  Can you ping me when it's done, so I can put up a ndt deploy request?
[14:33] <adeuring> deryck: sure
[14:33] <deryck> cjwatson, I don't know either.  But I'll check into it when I put the deploy request up.
[14:35] <cjwatson> ftpmaster (well, the bit of it that matters) is currently on 15032, so not that far back.
[14:36] <cjwatson> OK, LPS says it's still a separate 5-minute window.
[14:36] <deryck> ah yeah, just saw that too.
[14:36] <deryck> so we'll have to schedule that.
[14:36] <deryck> mrevell, we're doing a deploy later today that we need deployed to ftpmaster, and that needs 5 minute downtime.  How do we schedule that now?
[14:36] <deryck> mrevell, do you or danhg set that up?
[14:48] <mrevell> deryck, Hey, for five minutes just ask czajkowski to announce it to the status feed. Antu
[14:49] <mrevell> deryck, Anything more than that and I can find out when would have least impact on our stakeholders and users generally.
[14:49] <deryck> mrevell, ah ok.  I'll schedule with webops then and ping czajkowski when I know when they can do it.
[14:49] <czajkowski> deryck: just let me know the details more than 5 mins before hand and then I can get it out
[14:52] <deryck> czajkowski, will do, thanks
[15:41] <cjwatson> wgrant: hm, I meant to ask, did you feed my branch to EC2?
[15:41] <cjwatson> I guess I'll find out by the time you read this.
[16:36] <cjwatson> wgrant: ... never mind. :-)
[17:03] <sinzui> rick_h, jcsackett. Do you have time to review https://code.launchpad.net/~sinzui/launchpad/obsolete-js/+merge/99978
[17:04] <czajkowski> deryck[lunch]: am heading offline for EOD but will be back later if you want an annoucement put out.
[17:04] <rick_h> sinzui: will look at it now
[17:07] <deryck> czajkowski, ack.  I think it will likely be done tomorrow now.  waiting on QA for a branch.
[17:07] <czajkowski> deryck: ok well mail me and I can still annouce it in places for tomorrow
[17:07] <deryck> czajkowski, ok, thanks.
[17:16] <sinzui> rick_h, can you clarify the space issue now that I see it? I see two spaces...but I like code to be 4 spaces. Do you want me to make it 2 or 4 spaces
[17:17] <rick_h> sinzui: sorry, mean the space between the keyword 'function' and the parens
[17:17] <rick_h> sinzui: I think most LP people have no space between them, my background nad jslint are for a space
[17:18] <rick_h> sinzui: complete nitpick thing
[17:19] <sinzui> okay. I see that.
[17:20] <rick_h> other than that, thanks for finding and cleaning that up. One less thing for my long term JS clean up todo list :)
[17:23] <jcsackett> sinzui: i have followed up on rick_h, and have nothing to add. r=me.
[17:37] <sinzui> thanks jcsackett. I just extracted the script and ran it though lint. There were some == issues that also needed fixing
[17:37] <rick_h> doh, I should have caught those. Evil JS in .pt files...
[17:39] <rick_h> sinzui: have a sec for a quick ? on the subscribers stuff?
[17:39] <sinzui> sure
[17:39] <rick_h> sinzui: I'm trying to see where/how you test that once you have the notification bits working, that the event is bound correctly/working in the actual app layer through your configure.zcml bits?
[17:40] <rick_h> all the tests manually generate or call the event method that gets fired
[17:41] <sinzui> sorry, thunderbird-aka-shitehawk was stealing focu
[17:41] <sinzui> s
[17:43] <sinzui> rick_h, we have a utility that subscribes to the event that allows us to see it what was passed.
[17:43]  * sinzui looks for it in answers or registry
[17:46] <sinzui> rick_h, sorry, this time I could not find. it We use TestEventListener
[17:46]  * sinzui looks for real example of use
[17:46] <rick_h> ok, will search for that thanks
[17:47] <rick_h> that's ok, I can peek, just need a hint. Wasn't seeing it in the existing tests I was looking at
[17:48] <sinzui> rick_h, http://pastebin.ubuntu.com/905984/
[17:48] <sinzui> ^ the setup is odd because of the registration/deregistration of the listener
[17:49] <rick_h> ty much sinzui
[21:00] <wallyworld> sinzui: i *might* be a few minutes late to the standup. i have to drive my wife to work. hopefully traffic won't be too bad
[21:01] <sinzui> okay
[22:21] <sinzui> wgrant, wrong protocol on port -> http://pastebin.ubuntu.com/906352/
[22:22] <wgrant> sinzui: Yeah, that's speaking HTTPS to an HTTP listener.
[22:27] <sinzui> StevenK, I was thinking of bug #367533
[22:27] <_mup_> Bug #367533: Collapsible fieldsets don't degrade gracefully when Javascript isn't available <css> <easy> <javascript> <lp-web> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/367533 >
[22:28] <jelmer> g'd evenin' launchpadders
[22:29] <wgrant> Morning jelmer.
[22:34] <sinzui> StevenK, and bug #677339
[22:34] <_mup_> Bug #677339: filebug per-project help is below the fold <confusing-ui> <easy> <lp-bugs> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/677339 >
[22:53] <StevenK> wgrant, sinzui: https://www.destroyallsoftware.com/talks/wat