[00:02] <wgrant> lifeless: I believe so.
[00:03] <lifeless> [there's a few untriaged bugs in launchpad-project]
[00:03] <wgrant> Ah.
[00:20] <wgrant> lifeless: We need to delete gandwana and potassium.
[00:20] <wgrant> So many OOPSes with impossibly high non-SQL time on them.
[00:23] <huwshimi> wgrant: oh, thanks for triaging bug #737327... I forgot to change the status.
[00:23] <_mup_> Bug #737327: django should not be running in debug mode on production, it will eat all the RAM <OOPS Tools:Triaged> < https://launchpad.net/bugs/737327 >
[00:24] <wgrant> Also palladium
[00:26] <lifeless> wgrant: they are on the list
[00:29] <michaelh1> Hi there.  If I click on any merge request on staging I get either a timeout or an oops.  Have you seen this before?
[00:30] <lifeless> the testing librarian does not forward appserver requests to the prod one
[00:30] <lifeless> so you need to make a new merge proposal to test merge proposal stuff on staging
[00:31] <wgrant> Well, it's more that the staging librarian can't see restricted files from prod.
[00:31] <wgrant> And all MP diffs are restricted.
[00:32] <lifeless> wgrant: its not a token issue, it could forward
[00:32] <lifeless> its just a bug
[00:32] <wgrant> Right, but it's specific to restricted files.
[00:32] <wgrant> Not proxying.
[00:32] <lifeless> same thing
[00:32] <michaelh1> I'd like to play with merge requests from launchpadlib.  What would you suggest?
[00:33] <lifeless> make new ones on staging :)
[00:33] <lifeless> (actually, qastaging, its a better testbed)
[00:33] <michaelh1> That should work, ta.
[00:42] <lifeless> what does branchrevision.sequence is NULL imply ?
[00:44] <mwhudson> lifeless: off mainline
[00:45] <wgrant> Whoever named compiz should have thought about how much it would crash.
[00:45] <wgrant> It's very hard to start again when it dies and there is no z in your terminal buffer.
[00:48] <StevenK> wgrant: Alt-F1 ; DISPLAY=:0.0 compiz & ?
[00:48] <wgrant> StevenK: That breaks envvars when you're using unity.
[00:48] <wgrant> Since it appears to be a Compiz plugin now.
[00:48] <StevenK> There is no pleasing you.
[00:49] <lifeless> mwhudson: thanks
[00:57] <elmo> wgrant: kill unity, and start it again
[00:57] <elmo> wgrant: it'll bring up a new compiz instance
[00:57] <elmo> (from the terminal, I mean, i.e. the Alt-F1 scenario)
[00:59] <wgrant> elmo: With a real environment?
[00:59] <wgrant> So dbus apps won't cry?
[01:00] <elmo> wgrant: *shrug*, it WFM on natty without a real environemnt (just DISPLAY) - I just had to do it just now when unity suicided on me
[01:00] <wgrant> elmo: hm, OK, will try that in future. Thanks.
[01:00] <wgrant> Mine dies a few times a day at the moment... but I'm using r600g, so that's not too surprising.
[01:00] <elmo> I'm using Intel :(
[01:01] <wgrant> My Intel laptop is still safely on maverick.
[01:08] <poolie> hi all
[01:08] <wgrant> Afternoon poolie.
[01:09] <wgrant> ...
[01:10] <wgrant> Archive.sources_size and binaries_size.
[01:10] <wgrant> ...
[01:11] <StevenK> wgrant: What about them?
[01:11] <wgrant> Look at them.
[01:11] <StevenK> I don't want my eyes to bleed?
[01:11] <wgrant> It grabs every LFA and LFC in the archive.
[01:12] <wgrant> Ah, actually, just the filesizes. But all of them. Into python.
[01:12] <wgrant> Then sums them.
[01:12] <wgrant> In Python.
[01:13] <wgrant> It's probably not *that* slow. But it's stupid.
[01:13] <StevenK> Er, yeah. Now you that mention it, SQL can do the entire heavy lifting
[01:22] <StevenK> Hm. I think I can see the bug
[01:22] <StevenK> (Pdb) print spr.changelog.read()
[01:22] <StevenK> <security proxied lp.registry.model.sourcepackagename.SourcePackageName instance at 0x106ce390> (1.0-1derived1) unstable; urgency=low
[01:23] <wgrant> Er, what?
[01:24] <StevenK> I'm missing a .name
[01:24] <wgrant> Is this for tests?
[01:24] <StevenK> Yes
[01:24] <wgrant> Ah, good.
[01:24] <StevenK> Haha, I'm not that evil.
[01:34] <lifeless> man, so many soyuz bugs in 'incomplete wasused to clarify something and never changed' state
[01:34] <lifeless> lets see
[01:35] <lifeless> bugtask, dsitribution, cve all as much under control as they will be
[01:35] <lifeless> i guess its productset time
[01:35] <spm> bugs don't auto switchout of incomplete status after any additional info added do they? perhaps they could?
[01:36] <lifeless> pehraps
[01:36] <lifeless> expiry has had a difficult birth
[01:36] <lifeless> its not really battle tested
[01:36] <lifeless> I don't mean to indicate doubt about the idea; just that there are several ways to tackle it
[01:36] <lifeless> revamping status is bigger but perhaps worth it
[01:37] <lifeless> solve a bunch of headaches at once
[01:39] <spm> sure. I guess I've always viewed (anywhere) that bug status fields are project management fields - in my case, I'll update a bug, but typically won't change the status.
[01:40] <lifeless> indeed
[01:40] <lifeless> it can be frustrating for folk that identify with a project, when 'users' or bug filers change metadata
[01:50] <lifeless> wgrant: qa time I think
[01:50] <lifeless> wallyworld_: you too :)
[01:51]  * wallyworld_ want to finish some debugging first
[01:51] <wgrant> lifeless: A good point.
[01:52] <lifeless> wallyworld_: thats a priority inversion: unqaed stuff on trunk is a -blocker- and comes before all other work except production-is-down situations
[01:52] <lifeless> wgrant: I'm looking at sinzuis thing
[01:53] <wallyworld_> lifeless: ok. but it means a context switch. i'll get onto it though....
[01:53] <lifeless> wallyworld_: it does, and thats why I want us to drive the latency way down so a context switch is less often needed.
[01:54] <lifeless> wallyworld_: nevertheless, trunk is a critical section :(
[01:54] <wallyworld_> np.
[01:54] <wgrant> Baah
[02:07] <wallyworld_> lifeless: how do we test something that needs to access a diff when the data is not available via qastaging?
[02:07] <lifeless> mute is still behind a ff right ?
[02:07] <wgrant> Yes.
[02:07] <lifeless> wallyworld_: you need to make a new merge proposal or whatever
[02:07] <wallyworld_> ok
[02:11] <lifeless> wallyworld_: if you're very confident things will be better not worse, you can punt and go 'qa-untestable'
[02:12] <lifeless> the goal is to make a good tradeoff between time invested and risk of breaking stuff
[02:12] <wgrant> I don't think it's worth QAing that one.
[02:12] <wgrant> It's going to take a while.
[02:12] <wgrant> Apart from that we're OK to deploy.
[02:12] <wallyworld_> lifeless: np
[02:13] <lifeless> wgrant: do you need me to fire up evo and look at the mailbox ?
[02:14] <wgrant> lifeless: No, I got what I needed.
[02:14] <wgrant> Thunderbird just took a long time to download all few hundred thousand headers.
[02:14] <lifeless> wgrant: clear it out
[02:15] <wgrant> Just delete them?
[02:15] <lifeless> yeah
[02:15] <lifeless> its a test environment, not gmail :)
[02:15] <wgrant> Heh.
[02:15] <lifeless> hmm
[02:15] <lifeless> the tagger seems to be missing bugs :(
[02:15] <lifeless> see rev 12629
[02:16] <wgrant> The syntax in that commit message is invalid.
[02:16] <lifeless> wgrant: they are also linked to the MP
[02:16] <wgrant> Hmm.
[02:17] <lifeless> 411 exceptions
[02:17] <lifeless> nice
[02:17] <wgrant> Not really.
[02:17] <wgrant> It was less yesterday.
[02:17] <lifeless> down from 20K :P
[02:17] <wgrant> Shh.
[02:17] <lifeless> POFile:+translate is still in trouble
[02:17] <StevenK> wgrant: I think I may have thought of the only case we want to delete DSDs.
[02:18] <StevenK> wgrant: If the source is removed from both the child and parent distroseries.
[02:19] <wgrant> StevenK: Even then it's questionable. But maybe.
[02:19] <StevenK> wgrant: Questionable why?
[02:20] <wgrant> StevenK: There are situations in which the package could be deleted from both for a while and then restored. But the diff is unlikely to be important in that case, I guess.
[02:21] <wallyworld_> huwshimi: ping
[02:21] <huwshimi> wallyworld_: Hello
[02:21] <StevenK> wgrant: It's just a thought. I'm going to add two test cases to my end to end testing to see if the DSD gets updated on package deletion too.
[02:21] <wallyworld_> huwshimi: bug 580404
[02:21] <_mup_> Bug #580404: pressing enter in tags field doesn't save them <ajax> <javascript> <lp-bugs> <qa-ok> <Launchpad itself:In Progress by huwshimi> <LAZR Javascript Library:Fix Released by huwshimi> < https://launchpad.net/bugs/580404 >
[02:22] <wgrant> lifeless: You're requesting a deploy?
[02:22] <lifeless> wgrant: in about 75 minutes
[02:22] <wallyworld_> i qa-oked it but it doesn't seem to properly fix the issue
[02:22] <lifeless> wallyworld_: do we need to roll it back ?
[02:22] <wgrant> lifeless: The portlet fix?
[02:22] <lifeless> wallyworld_: or is it ok to deploy, just incomplete?
[02:22] <lifeless> wgrant: yes
[02:22] <wallyworld_> huwshimi: no, since it doesn't break anything, but it doesn't seem to properly fix it
[02:23] <lifeless> wallyworld_: then its qa-ok
[02:23] <wallyworld_> lifeless: i know that
[02:23] <StevenK> Here Comes The Rain (to the tune of Slayer's Here Comes The Pain)
[02:23] <lifeless> wallyworld_: ok :) - was unsure what you're saying then
[02:23] <wallyworld_> i just wanted to see if i was testing proerly
[02:23] <wallyworld_> in case we needed to raise a new bug
[02:24] <lifeless> wallyworld_: In this sort of case I add a comment to the bug saying 'does not fix' and whoever does the deploy will put it back to in-progress
[02:24] <huwshimi> wallyworld_: It isn't testable until we release a new version of lazr-js with Launchpad. Which I've been distracted from doing
[02:25] <wallyworld_> lifeless: thanks for the tip
[02:26] <lifeless> thumper: bug 615647 - I've played around for a more efficient query, and it seems to work ok to me; could you eyeball it and check I haven't missed anything?
[02:26] <_mup_> Bug #615647: BranchMergeProposal:+index timeout <lp-code> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/615647 >
[02:27] <wallyworld_> huwshimi: i have uploaded rev 206 of lazrjs to the download cache. still getting the branch that needs it fully debugged
[02:27] <wallyworld_> huwshimi: are your changes done prior to rev 206? if so, they
[02:27] <wallyworld_> will get rolled out when 206 goes in
[02:28] <huwshimi> wallyworld_: yeah they're in 204
[02:28] <huwshimi> wallyworld_: Thanks
[02:29] <wallyworld_> huwshimi: np. i'll try and get my branch through today. gotta fix some failing tests
[02:39] <huwshimi> Is there any way to add a class with a condition using TAL. More specifically I want to add the class 'hidden' to a div under a certain condition. The div already has other classes, just to complicate things.
[02:40] <lifeless> huwshimi: probably best to do that in the view
[02:42] <huwshimi> lifeless: Really? It seems like the sort of thing that should be done in a template?
[02:43] <wgrant> It belongs in the template. But it's difficult and ugly to do it there.
[02:43] <lifeless> huwshimi: if you want to do conditional logic you want a real programming language
[02:43] <lifeless> huwshimi: either js, or python, not -ever- tal
[02:44] <huwshimi> lifeless: Oh, but we have heaps of conditional stuff in our templates.
[02:44] <lifeless> huwshimi: which has a bunch of poor sideeffects
[02:44] <lifeless> such as:
[02:45] <lifeless>  - timeouts (tal:when used on a collection that triggers an additional count(*) of an expensive query)
[02:45] <lifeless>  - complex templates that can't be used in multiple contexts
[02:46] <lifeless>  - expensive tests (need to test complete rendering - and rendering uses the whole stack- for more code paths)
[02:47] <lifeless> huwshimi: I'm exaggerating a /little/ for effect, but templates are really not suitable for anything but the simplest of conditionals, and tal inparticular, with its obsession on document structure as a pun for program logic makes this substantially worse when you're not dealing with a dom subtree
[02:51] <lifeless> wgrant: btw - high nonsql time is (IME) correlated with repeated lookups; I suspect storm GIL handling exacerbates high load situations (e.g. too many handoffs)
[02:52] <wgrant> lifeless: Quite possibly, yes.
[02:53] <lifeless> (so fixing such timeouts is easily possible via code  :P)
[02:53] <lifeless> hmm
[02:53] <lifeless> makeCodeImport() doesn't create the branch ?
[02:53] <lifeless> or... not scanned I guess
[02:58] <huwshimi> lifeless: What I'm doing is purely to do with presentation (and handling broken situations with no javascript). If from what I understand you mean we should be returning css classes from the python view (which I've seen elsewhere in Launchpad) which I think is a bad idea (it tightly couples CSS to views, which makes things less re-usable and a lot harder to change), if anything we should be returning boolean flags wh
[02:58] <huwshimi> ich we can check against to modify the template accordingly  (which is what we have already in this case).
[03:11] <huwshimi> lifeless: At this point it looks like my best bet is to duplicated a chunk of HTML under 'condition' and 'condition not:'
[03:14] <lifeless> huwshimi: I suspect thats more of a maintenance burden than I was suggesting.
[03:14] <lifeless> huwshimi: in terms of reuse and change, I haven't seen anything in tal that makes it easier to change than a view, and we have nearly universally a 1:1 view->template mapping anyway.
[03:15] <lifeless> huwshimi: which, I admit, may be because we have things all funky at the moment.
[03:16] <huwshimi> lifeless: So really we have this limitation of having views return classes due to limitations with our templating language?
[03:16] <lifeless> huwshimi: I think we have different perspectives.
[03:16] <lifeless> huwshimi: you say you are working on presentation, right ?
[03:17] <huwshimi> lifeless: Correct
[03:17] <lifeless> huwshimi: view objects *are* the presentation layer
[03:17] <lifeless> huwshimi: templates are bound to a view for convenient editing of the html
[03:17] <lifeless> huwshimi: but its not a limitation, bug or defect to do html in the view.
[03:19] <lifeless> including complex logic for deciding on things - like initial visibility
[03:19] <lifeless> huwshimi: I'll note that duplicating a section of html in the TAL will have a negative impact on performance
[03:20] <huwshimi> lifeless: OK I see where our opinion differs.
[03:20] <huwshimi> lifeless: Although I would say that it is a limitation of our templating language that we can't properly manipulate the HTML it ouputs.
[03:21] <lifeless> huwshimi: TAL is in some ways /extremely/ primitive; the implementation we use is also very slow - the work gary and others have done to make chameleon available will, when complete, help with performance a lot
[03:21] <lifeless> in other ways TAL is pretty nice
[03:23] <huwshimi> lifeless: So for this I should move all my classes on this div into the view and return them depending on conditions there?
[03:24] <lifeless> huwshimi: both wgrant and I reacted that way, without having seen the exact situation
[03:25] <wgrant> Except I say it's a necessary evil, and lifeless says it's good.
[03:26] <StevenK> Hm, I wonder how far chameleon is off
[03:27] <huwshimi> wgrant: I think it's particularly evil cause you can't separate out the classes that should be returned on the condition to the ones that should always be applied :(
[03:28] <wgrant> huwshimi: Yup.
[03:29] <mwhudson> you could do tal:attributes="class string: always ${view/optional}" or something?
[03:29] <wgrant> True.
[03:31] <huwshimi> mwhudson: Can you explain that to me?
[03:32] <mwhudson> huwshimi: which bit?
[03:32] <thumper> lifeless: public holiday here today :)
[03:32]  * thumper is off all week
[03:32] <wgrant> Thunderbird has managed to use 6.5GiB of RAM.
[03:32] <wgrant> I am impressed.
[03:33] <mwhudson> huwshimi: maybe this bit? http://docs.zope.org/zope2/zope2book/AppendixC.html#tales-string-expressions
[03:33] <lifeless> thumper: orly ?
[03:33] <lifeless> thumper: I wants :P
[03:34] <huwshimi> mwhudson: Thanks I'll take a look
[03:35] <lifeless> huwshimi: the word always would be a class you want present no matter what
[03:38] <wgrant> lifeless: Do you have any thoughts on extending BrowsesWithQueryLimit to help with scaling tests?
[03:39] <wgrant> ie. I want to specify a maximum baseline, test the baseline, then test that it doesn't scale above that.
[03:44] <lifeless> wgrant: do you mean 'allow it to do LessThan' ?
[03:44] <StevenK> typos in URLs make me sad.
[03:45] <wgrant> lifeless: I guess I want the matcher to remember the last value it checked, and use that as the max for future calls.
[03:46] <lifeless> wgrant: so, this would permit accidental increases in baseline
[03:46] <lifeless> wgrant: but be more tolerant of deliberate increases in core infrastructure
[03:46] <wgrant> lifeless: It would still have an initial value.
[03:47] <wgrant> But would use the last checked value in preference.
[03:47] <lifeless> wgrant: so it would ratchet down
[03:47] <wgrant> Right.
[03:47] <lifeless> so the failure you are preventing is 'someone set the initial value way to high'
[03:48] <wgrant> More "someone improved other stuff, so the initial value is now way too high and nobody noticed because we use LessThan instead of Equals"
[03:48] <lifeless> wgrant: you can do this if you want, should be a small matter of code; I don't have a strong opinion any which way.
[03:48] <lifeless> wgrant: as an alternative, perhaps error if the query count is *too low*
[03:49] <wgrant> lifeless: That's what I suggested last week, but you seemed neutral/negative.
[03:49] <lifeless> wgrant: did I? sorry.
[03:49] <wgrant> Quite reasonably, because it's more sensitive to widespread query reductions.
[03:50] <wgrant> I'm not sure which concern should win.
[03:50] <lifeless> wgrant: did you suggest users supplying a minimum, switching to Equals, or having a heuristic ?
[03:51] <wgrant> lifeless: Switching to Equals.
[03:51] <wgrant> Users supplying a minimum is silly.
[03:51] <lifeless> wgrant: ah
[03:51] <wgrant> And a heuristic is a heuristic.
[03:51] <lifeless> wgrant: so I'm suggesting using a heuristic, not switching to equals
[03:51] <lifeless> wgrant: one such heuristic would be 'allow off by 1'
[03:51] <lifeless> another would be
[03:51] <lifeless> 'alllow a 10% margin below the count given'
[03:52] <lifeless> wgrant: I'm still neutral/negative on using equals. I think we need some slack.
[03:53] <lifeless> thumper: whats the holiday?
[03:54] <lifeless> I can has review? https://code.launchpad.net/~lifeless/launchpad/bug-734751/+merge/54146
[03:55] <wgrant> lifeless: "allow off by 1" rots, "allow a 10% margin below the count given" is going to miss scaling issues.
[03:56] <wgrant> Unless the 10% margin only applies to the first time.
[04:03] <lifeless> wgrant: i like the idea of combing a heuristic and an observed cap
[04:03] <lifeless> combining*
[04:19] <lifeless> 5 second portlets still suck, but at least its less suck
[04:36] <wallyworld_> anyone feel like reviewing https://code.edge.launchpad.net/~wallyworld/launchpad/unassign-private-bug/+merge/53945
[04:37]  * StevenK slaps wallyworld_ for pasting edge URLs
[04:37] <wallyworld_> ouch
[04:37] <wallyworld_> stupid browser cache
[04:39] <StevenK> wallyworld_: Why do you have a return at the end of _cacheViewPermission()?
[04:39] <wallyworld_> StevenK: cause i'm stupid. it's a typo
[04:40] <wallyworld_> StevenK: actually no
[04:40] <wallyworld_> it's to exit the loop as soon as a match is found
[04:40] <StevenK> Ah, right
[04:41] <wallyworld_> StevenK: notice how my first reaction was to think how dumb i am :-)
[04:43] <lifeless> wgrant: wallyworld_: StevenK: I'm tired of my merge proposals timing out. So have fixed. Could one of you eyeball this please: https://code.launchpad.net/~lifeless/launchpad/bug-615647/+merge/54150
[04:43]  * wallyworld_ looks
[04:43] <lifeless> if you're not a full reviewer thats ok - I'm going to self review, this thing is going down ;)
[04:43] <StevenK> No diff yet
[04:44] <StevenK> wallyworld_: If you can confirm self.bug in the context of those two tests is private, r=me
[04:44]  * wallyworld_ looks
[04:45] <lifeless> wallyworld_: reviewed.
[04:45] <wallyworld_> thanks.
[04:46] <wallyworld_> StevenK: self.bug is created in the test setup
[04:47] <StevenK> wallyworld_: I'm abstaining, due to lifeless' review of your MP
[04:48] <StevenK> WTF, how hard can it be to switch DB users
[04:49] <wallyworld_> lifeless: do we really know that the current user has permission? what if they were removed from a team after they had already opened the page?
[04:50] <StevenK> self.layer.switchDbUser() insists that LaunchpadFunctionalLayer doesn't have that method, and LaunchpadZopelessLayer.switchDbUser() gives ZopelessTransactionManager not installed
[04:50] <lifeless> wallyworld_: then how do they reach the code to call unassign?
[04:51] <wallyworld_> lifeless: might they have the page open and before they go to unassign, they are removed from the team by someone else. on their browser, they are still assigned
[04:52] <wallyworld_> so they could concievably stil lmake the api request to the back end
[04:52] <lifeless> wallyworld_: then the publishing code will return a 404 to the POST
[04:52] <wallyworld_> ok
[04:53] <wallyworld_> so i'll take away the checks and just add the user to the cache
[04:53] <lifeless> wallyworld_: and move the code
[04:54] <wallyworld_> to?
[04:55] <lifeless> wallyworld_: in fact, this is a self inflicted bug :)
[04:55] <lifeless> wallyworld_: have you got transitionToAssignee open ?
[04:56] <wallyworld_> lifeless: no
[04:56] <wallyworld_> but i can
[04:56] <lifeless> grab it now
[04:56] <wallyworld_> open
[04:56] <lifeless> look at the last line of the third if block
[04:57] <wallyworld_> you mean clearing the cahce?
[04:57] <lifeless> it explicitly enforces cache coherency on the viewers, *discarding* the fact that the active user can see the bugtask.
[04:58] <lifeless> this is in conflict with the intent of your change which is to 'permit the user to view stuff that they *could* even if they *can't now*
[04:58] <wallyworld_> yeah, i didn't really know this bit of the code base that well. just found what looked like would work
[04:59]  * StevenK glares at the apartment above him
[04:59] <lifeless> wallyworld_: http://pastebin.com/iwLt6zhw
[04:59] <StevenK> Some ingrateful muppet is using a hammer drill
[04:59] <lifeless> wallyworld_: seems to be all that is needed to me - + a test that tests the launchpadlib call works
[05:00] <wallyworld_> lifeless: i think it's more than just changing the assignee though. from memory, the same issue cam up when unsubscribing oneself
[05:00] <wallyworld_> and the change i did sorted out that issue too
[05:00] <wallyworld_> but that was last week. i may have misremembered
[05:01] <wallyworld_> i'll look into it
[05:01] <lifeless> wallyworld_: there is a separate method for unsubscribe
[05:01] <lifeless> looks like an identical bug
[05:01] <wallyworld_> yeah, probs
[05:01] <lifeless> the reason I think the lifecycle change, while elegant, is a problem, is because we have direct cache management - and the two will stomp on each other.
[05:02] <lifeless> the first like of unsubscribe needs to either be more selective about what it clears, or to keep the known viewers list.
[05:02] <lifeless> https://code.launchpad.net/~lifeless/launchpad/bug-615647/+merge/54150 has a diff up
[05:03] <wallyworld_> lifeless: your unmerged revisisions change - is the order by BranchRevision.branch desc necessary?
[05:04] <wallyworld_> lifeless: i'm late to pick up the kid from school. back soon
[05:04] <lifeless> it selects the right index
[05:04] <lifeless> wallyworld_: the index is on (branch, sequence)
[05:04] <lifeless> wallyworld_: it /may/ work without it. It /does/ work with it - see the various test plans in the bug
[05:28] <wgrant> Anyone want to review https://code.launchpad.net/~wgrant/launchpad/trim-asp/+merge/54152?
[05:29] <StevenK> wgrant: r=me
[05:29] <wgrant> StevenK: Thanks.
[05:29] <StevenK> wgrant: Can haz help switching db user?
[05:30] <wgrant> StevenK: Use LaunchpadZopelessLayer.
[05:30] <wgrant> Call LaunchpadZopelessLayer.switchDbUser
[05:30] <StevenK> wgrant: Does that allow me to upload to the librarian?
[05:30] <wgrant> StevenK: Yes.
[05:30] <wgrant> "Launchpad" generally means that the librarian is up.
[06:22] <lifeless>  bah, no stubs
[06:22] <StevenK> He was here
[06:22] <lifeless> yes
[06:22] <lifeless> was
[06:22] <lifeless> timed out 2 minutes back
[06:30] <lifeless> StevenK: can you do a review for me ?https://code.launchpad.net/~lifeless/launchpad/bug-734751/+merge/54146
[06:33] <StevenK> lifeless: rme
[06:33] <lifeless> StevenK: thanks
[06:33] <StevenK> Sprinkle = to taste
[06:39] <poolie> wgrant, re the mail mangling
[06:40] <poolie> i have to say tim's thing a while ago that spam causes the headers to be inserted into the body gives me a queasy feeling about lp mail handling
[06:40] <wgrant> poolie: Yes.
[06:41] <wgrant> poolie: This is a good excuse to examine those configs and unbreak it.
[06:43] <wgrant> I don't entirely know what the incoming mail path is :/
[06:49] <StevenK> wgrant: Ask a friendly* sysadmin?
[06:53] <poolie> is that a Kleen star? :-)
[06:53] <poolie> lifeless, it's not top of my list (nor i dare say yours) but i was wondering after friday's mail what your actual thoughts on triaged vs confirmed were
[06:54] <poolie> are you also hoping to merge them?
[07:53] <StevenK> henninge: O hai! I have one for you :-)
[07:53] <henninge> Hi StevenK! Let me see it ;-)
[07:54] <StevenK> henninge: https://code.launchpad.net/~stevenk/launchpad/dsdj-runner/+merge/54159
[08:29] <lifeless> poolie: that 3 page bug update is about as far as my thinking has advanced
[08:31] <lifeless> poolie: I think that 'triaged' as it stands is entirely redundant, but that piecemeal solutions probably aren't [solutions]
[08:46] <adeuring> good morning
[08:53] <StevenK> henninge: No news means "It's terrible, redo from start" ? :-)
[08:54] <henninge> StevenK: no, it looks good
[08:54] <henninge> StevenK: Still a lot to read ...
[08:58] <rvba> henninge: Hi, once you're finished with StevenK's branch, I'd appreciate if you could take a look at https://code.launchpad.net/~rvb/launchpad/dds-sampledata/+merge/53988
[09:01] <StevenK> rvba: Julian approved that MP?
[09:01] <rvba> StevenK: yes
[09:07] <henninge> rvba: why would you want another review if it has already been approved?
[09:08] <rvba> henninge: well ... I thought the procedure was to have it reviewed by someone outside the circle of people who discussed the branch in question
[09:09] <henninge> rvba: good point
[09:09] <rvba> henninge: but in this case, it's really tiny and does not involve code change (only sql in current-dev.sql) so it might not be worth you time
[09:10] <rvba> s/you/your/
[09:10] <henninge> rvba: yeah, there is really not much I can review here.
[09:10] <rvba> henninge: all right then
[09:10] <henninge> rvba: how did you create the sample data?
[09:11] <rvba> henninge: I confess I did that manually (fiddling with the database), then I ran make newsampledata
[09:11] <rvba> probably not the most clever way to do this I know
[09:12] <henninge> rvba: well yeah, usually it's better to do that through the normal procedures (i.e. UI and scripts)
[09:12] <henninge> rvba: actualy it's *best* to avoid creating new sample data at all.
[09:12] <henninge> well, actually it's more about using it in tests, I guess.
[09:12] <rvba> henninge: yes but the scripts to create those objects are in the works now
[09:12] <henninge> which is not the case here, of course.
[09:13] <henninge> I figured
[09:13] <rvba> yes, I only modified the sampledata for local instances
[09:13] <henninge> oh, right
[09:13] <henninge> rvba: r=me in that case ;-)
[09:14] <rvba> the goal is to populate a form on which I'll have some js work to do pretty soon, before the scripts to populate this with real data exist
[09:14] <rvba> henninge: thx
[09:19] <henninge> StevenK: Isn't there some existing infrastructure to test scripts so you don't have to do the subprocess dance?
[09:22] <henninge> StevenK: what about "from canonical.launchpad.scripts.tests import run_script"
[09:30] <danilos> henninge, good morning, one very complex branch for you when you can find 10 minutes: https://code.launchpad.net/~danilo/launchpad/mail-header-discrepancy/+merge/54172 :)
[09:31] <henninge> Hi danilos!
[09:31] <henninge> and "No" :-P
[09:31] <henninge> (which means "Yes", of course)
[09:31] <StevenK> henninge: Hm, wasn't sure about that. I can certainly look at changing it.
[09:31] <henninge> StevenK: I'll give you an example in the review.
[09:31] <henninge> see if that works for you
[09:32] <StevenK> henninge: Awesome.
[09:32] <danilos> henninge, excellent, I prefer "no" meaning "yes" than the other way around :)
[09:32] <henninge> ;)
[09:32] <danilos> henninge, and I love you :)
[09:33]  * henninge blushes
[09:41] <henninge> StevenK: review sent
[09:44] <henninge> danilos: sorry, too complex to do in one OCR shift, you will hear back from me tomorrow night.
[09:44] <danilos> henninge, I understand, thank you for trying anyway!
[10:47] <wgrant> Erm.
[10:47] <wgrant> Why is ~registry not a member of ~vcs-imports any more?
[10:48] <lifeless> it was via launchpad-chr, which matsubara deleted for some reason a couple of weeks back
[10:48] <wgrant> Ah. Can you readd?
[10:48] <wgrant> ALthough I guess we then need a ~launchpad admin :(
[10:49] <jelmer> doesn't ~canonical-bazaar own it now for some reason?
[10:50] <wgrant> lifeless is an admin.
[10:50] <wgrant> But adding a team to another requires confirmation from both ends.
[10:50] <lifeless> sure, one sec
[10:51] <lifeless> hangon, ~registry or ~launchpad into vcs-imports ?
[10:52] <lifeless> wgrant: ^
[10:52] <wgrant> ~registry is basically the semi-admin team now... it's basically ~launchpad + ~canonical-bazaar plus a few others. I would go with ~registry.
[10:52] <wgrant> But it doesn't really matter.
[10:53] <lifeless> huh, I own but am not in registry. shrug
[10:53] <lifeless> anyhow, added.
[10:53] <wgrant> You are in registry.
[10:53] <wgrant> It's a display bug.
[10:53] <wgrant> Thanks.
[10:56] <wgrant> lifeless: https://lists.launchpad.net/registry/msg32632.html
[10:57] <wgrant> Odd.
[10:57] <lifeless> yes, that was sent out when he deleted launchpad-chr
[10:57] <lifeless> the message is confusing because it doesn't describe the action taken
[10:57] <wgrant> That makes very little sense.
[10:58] <lifeless> that he deleted -chr, or that it took it out of the team ?
[10:58] <wgrant> That is sent when a teammembership is deactivated. launchpad-chr deletion would not have done that.
[10:58] <lifeless> deleting the team merges it to registry right? and deactivates all previous team memberships ...
[10:58] <wgrant> Right. But it deactivates before the merge.
[10:58] <lifeless> right
[10:59] <wgrant> Hmm.
[10:59] <wgrant> Ahh.
[11:01] <henninge_> jtv: Hi!
[11:01] <deryck> Morning, folks.
[11:01] <henninge_> Hi deryck!
[11:01] <jtv> Hi henninge!
[11:01] <jtv> Just looking at the import queue, as it happens.
[11:01] <henninge_> uh-oh
[11:02] <henninge_> jtv: what's up with it?
[11:02] <jtv> Nothing, that's the great thing.
[11:02] <henninge_> cool
[11:02] <jtv> I'm just emailing the uploader of an RT template about branch synchronization.
[11:03] <henninge_> jtv: I was going to ask you for a review but now that deryck is here I can ask him , too. ;-)
[11:03] <jtv> oh sweet :)
[11:03] <jtv> Just out of interest, what are you working on?
[11:03] <deryck> henninge_: sure, I can do a review.
[11:03] <henninge_> jtv: still finishing of upstream sharing UI
[11:03] <jtv> Ah
[11:04] <jtv> Saw that you'd been working on that—very nice to know that we're getting some visibility into sharing.
[11:05] <henninge> jtv, deryck: Here is the mp. I have to go out now for an hour so it might not be optimal for you, jtv, since you are towards EOD.
[11:05] <henninge> jtv: but it's using POTemplateCollections! ;-)
[11:05] <henninge> https://code.launchpad.net/~henninge/launchpad/devel-737422-remove-translationsharinginfo/+merge/54184
[11:06] <jtv> henninge: yes, I'm EOD now and have to rush to a dinner appointment…  but cool stuff!
[11:06] <henninge> jtv: enjoy it!
[11:06] <henninge> deryck: thanks, that OCR is ignoring me ...
[11:06] <deryck> henninge: heh.  np.
[11:09] <jtv> henninge: dankeschön, und bis morgen :)
[11:12] <jtv> hi salgado!
[11:13] <salgado> hi jtv!
[11:13] <jtv> everything good?
[11:14] <salgado> yep! and you?
[11:18] <jtv> Great, thanks!  Narrowly avoided arrest over the two empty cartridges I brought home from Dallas.  :)  Gotta run now!
[11:20] <salgado> that sounds like lots of fun. ;)
[11:44] <cjwatson> I'd like to have a pre-implementation chat with somebody about adding support for .orig.tar.xz files in package uploads
[11:45] <cjwatson> henninge-out: you're listed as OCR, but I guess not because you're out? :)
[11:50] <wgrant> cjwatson: I did the last round of changes there, so I might be a reasonable person to talk to.
[12:16] <gmb> benji: Morning. Can I get a review for https://code.launchpad.net/~gmb/launchpad/finish-it-bug-737648/+merge/54189 please?
[12:16] <benji> gmb: sure
[12:17] <gmb> Ta
[12:23] <benji> gmb: done: https://code.launchpad.net/~gmb/launchpad/finish-it-bug-737648/+merge/54189
[12:24] <gmb> benji: Thanks. WRT your point about tests, I can only say: Oh boy, you don't want to know.
[12:24] <cjwatson> wgrant: OK; well, I just went through and grepped for bzip2, bz2, and orig.tar, and added xz to anything that currently handles bz2
[12:24] <benji> heh
[12:24] <cjwatson> wgrant: the changes were confined to archiveuploader, except for a comment change in soyuz/enums.py; does that sound reasonable?
[12:24] <cjwatson> wgrant:
[12:24] <cjwatson> http://paste.ubuntu.com/583299/
[12:25] <wgrant> cjwatson: Do we need additional series restrictions on that? 3.0 is permitted in >= Karmic.
[12:26] <wgrant> +        # each component, and can use gzip, bzip2, or compression.
[12:26] <wgrant> missing 'xz'
[12:26] <wgrant> It almost seems worth generalising the compression type check, but not quite, so that looks reasonable.
[12:28] <cjwatson> missing> whoops
[12:29] <cjwatson> series> hmm.  orig.tar.xz requires dpkg >= 1.15.5, so we probably want >= lucid here.
[12:29] <wgrant> :(
[12:30] <wgrant> Meh.
[12:30] <wgrant> karmic can burn.
[12:30] <wgrant> Worst case the buildds will explode and fail the build in bad ways.
[12:30] <wgrant> Plus Karmic dies in a month, right?
[12:33] <sidnei> lifeless or gary_poster, around by any chance?
[12:33] <gary_poster> sidnei, hi
[12:33] <sidnei> hey gary_poster
[12:34] <sidnei> gary_poster, would you know from memory why the page performance reports are generated from tracelog instead of using the oops system?
[12:34] <gary_poster> sidnei, yes.
[12:34] <gary_poster> 1) oops system only has exceptional circumstances
[12:34] <gary_poster> (we want all)
[12:35] <gary_poster> 2) tracelog has inter-request numbers that no other output has (how long request has been waiting)
[12:36] <gary_poster> mm, "no other output" == "no other output I know of" :-P
[12:37] <gary_poster> 3) we were starting from existing similar work with the tracelog
[12:37] <gary_poster> that's all I can think of sidnei
[12:39] <sidnei> gary_poster, ok. we're considering running ppr for landscape, but therve suggests that we enable oops for all requests, which would address (1), and afaict, we're limiting the number of concurrent requests to the number of threads in haproxy, which would address (2)
[12:40] <sidnei> i think we might still got with tracelog just because it requires less changes though
[12:41] <gary_poster> sidnei, ack with #2, same for us; tracelog gives you visibility into Zope bits, which as you said, should be controlled by haproxy, but might not.  I think we are only looking at haproxy results too, tbh and afaik.
[12:41] <gary_poster> (for #2 values)
[12:43] <gary_poster> sidnei, I vaguely would like to share code with you all, but don't strongly care otherwise.  Another thing to consider maybe is cost of generating oopses.  tracelog is designed to be very fast; oops reports do a lot more, so I would expect them to be a lot more expensive.  Just guessing though, dunno.
[12:46] <henninge> cjwatson: I am back
[12:46] <sidnei> gary_poster, thanks!
[12:46] <gary_poster> np
[12:47] <cjwatson> wgrant: where is the 3.0 >= karmic check implemented?
[12:47] <wgrant> cjwatson: A table, SourcePackageFormatSelection.
[12:47] <cjwatson> henninge: thanks - I think I can continue with wgrant
[12:48] <cjwatson> wgrant: if you don't feel bad about spuriously allowing xz in karmic, I don't either
[12:48] <wgrant> cjwatson: So adding another is a fairly heavyweight thing.
[12:48] <cjwatson> as you say, it will almost certainly simply fail to build
[12:48] <wgrant> cjwatson: Sounds good.
[12:50] <henninge> cjwatson: oh, that's cool. I did not read the backscroll ;-)
[12:51]  * deryck reboots, back shortly.....
[12:52]  * maxb idly wonders if there is a reason why anyone can give away projects to arbitrary launchpad users, but can't give away branches similarly
[13:01] <jelmer> maxb: I don't think there is a reason..
[13:02] <wgrant> It's possibly an impersonation risk.
[13:02] <wgrant> (so is project ownership transferral, but that's a bug, like team memberships)
[13:10] <danilos> mrevell, hi, can you perhaps come up with something that looks more like English for what I am trying to achieve here: https://pastebin.canonical.com/44947/ :)
[13:10] <danilos> mrevell, what's going on is that we've got a X-Launchpad-Subscription header, *and* "Matching subscriptions: subscription1, subscription2" text in the body of the email for those poor gmail users
[13:14] <dobey> "an X-Launchpad-Subscription header"
[13:14] <wgrant> Can we please have a "My email provider is stupid" checkbox to declutter text for those of us with sensible filtering mechanisms?
[13:14] <wgrant> It could even default to true for gmail.com accounts.
[13:17]  * henninge relocates
[13:21] <allenap> benji: Do you have time to review a mostly-javascript branch? https://code.launchpad.net/~allenap/launchpad/dd-initseries-bug-727105-architecture-picker/+merge/54173
[13:21] <benji> allenap: sure
[13:21] <allenap> benji: Thanks :)
[13:45] <deryck> henninge: this is a nice refactor. Don't really have any questions about it. r=me
[13:46] <henninge> deryck: thanks
[13:46] <henninge> deryck: I have some failing tests, though ... :(
[13:46] <deryck> henninge: oh, bummer
[13:47] <mrevell> danilos, Will take a look now.
[13:48] <danilos> mrevell, thanks
[13:51] <deryck> henninge, abentley -- I'm having serious connection issues this morning and working with cable company to debug.... may not make standup time.
[13:52] <abentley> deryck: I've got SkypeOut, so we can do it on POTS if that helps.
[13:52] <deryck> abentley: I'm on the phone with cable company now, sorry
[13:53] <abentley> deryck: cool.
[13:53] <deryck> abentley, henninge -- sorry.  if you guys will just carry on without me.
[13:53] <deryck> hi adeuring.  see ^^
[13:54] <adeuring> deryck: ok, noted
[13:54] <deryck> I may loose connection here some as I debug this, too.
[13:54] <abentley> deryck: Sure, if that's what you want.
[13:55] <henninge> deryck: ok, good luck with the cable company. ;)
[13:56] <deryck> henninge: thanks
[14:22] <abentley> leonardr: is there a version of testing._webservice.api_url which is suitable for production use?
[14:23] <leonardr> abentley: i don't know. what exactly do you want to do?
[14:23] <leonardr> i think in production you can convert the current browser request to a web service request and then use canonical_url
[14:24] <abentley> I want to create a view which returns a json-serialized dict that I will use to initialize the javascript functionality of a page.
[14:25] <abentley> deryck: This serialized dict would need to include the API urls of several objects.
[14:26] <leonardr> abentley: if i understand you correctly, we have a mechanism for that already. let me look it up
[14:26] <abentley> leonardr: cool.
[14:29] <deryck> abentley: was that info for me, or just chatting with leonardr?
[14:29] <abentley> deryck: for leonardr.  Sorry.
[14:29] <deryck> np
[14:30] <leonardr> abentley: the thing we have already is: you can put an object in the IJSONRequestCache and when the launchpad page is rendered, the json representation of that object will be available through lp.cache.objects (or something like that)
[14:30] <leonardr> lib/lp/bugs/browser/bugtask.py:        IJSONRequestCache(self.request).objects['bug'] = bug
[14:33] <leonardr> oh, even better
[14:34] <leonardr> you can put the object in IJSONRequestCache(self.request).links['key']
[14:34] <leonardr> and only the link will show up
[14:34] <leonardr> see lib/canonical/launchpad/rest/me.py
[14:36] <abentley> leonardr: you are a beautiful man.
[14:36] <leonardr> abentley: i've always thought so
[14:44] <benji> allenap: done (https://code.launchpad.net/~allenap/launchpad/dd-initseries-bug-727105-architecture-picker/+merge/54173)
[14:44] <allenap> benji: Awesome, thank you :)
[15:07] <jelmer> jcsackett: it looks like the instructions for vcs imports are outdated - sourceforge doesn't work with non-https at the moment
[15:08] <jcsackett> jelmer: oh fantastic. :-P
[15:08] <jcsackett> thanks for letting me know. :-)
[15:08] <jcsackett> i'll update.
[15:08] <jelmer> jcsackett: I guess technically that still means plain http is faster than https ;-)
[15:08]  * jcsackett laughs.
[15:11] <jcsackett> and the offending line is removed.
[15:21] <leonardr> benji, i have a zope question
[15:21] <benji> leonardr: hit me
[15:21] <leonardr> take a look at lazr.restful metazcml.py
[15:21] <leonardr> there's a 'register_webservice' option
[15:22] <leonardr> er, action
[15:22] <leonardr> the kind of thing you put in a zcml file
[15:22] <leonardr> i added a 'webservice sanity checks' action to the end of it
[15:22] <leonardr> which is supposed to run after the web service is fully registered
[15:22] <leonardr> the problem is that in launchpad, register_webservice is called no less than 12 times
[15:23] <leonardr> the sanity checks will only succeed if they are called _last_
[15:23] <leonardr> i could add a separate sanity_checks option to go into the zcml file, but how can i guarantee that it's run after everything else?
[15:23] <benji> hmm, that's a good question; let me look at it for a second
[15:26] <leonardr> benji: the other problem is that during register_webservice i build up lists of the things that need to be sanity-checked. is there any safe place to store that information for another zcml action to pick it up?
[15:28] <benji> leonardr: on that front a module global would appear to be your best bet; that approach would cause problems if ZCML processing was ever parallelized, but I bet lots of other implementation details would fall over too so doubt that will ever happen
[15:35] <allenap> jml: Do you have time to review a very small testing-related branch?
[15:35] <jml> allenap: how could I say no?
[15:35] <allenap> jml: I hoped you'd say that :) https://code.launchpad.net/~allenap/launchpad/id-for-yui-test-cases/+merge/54229
[15:36] <allenap> jml: I'm asking you because you'll be able to tell me if it's sane or not.
[15:36] <jml> allenap: Looks basically sane to me. Two things come to mind.
[15:36] <jml> allenap: first is that you should add a test for this.
[15:37] <jml> allenap: second is that the ideal id() allows you to load the test based on the id. I don't know enough about how JS tests are run to know if that's the case here. It seems likely though.
[15:37] <allenap> jml: Fair. This whole class is untested so I was hoping to sneak this one through too.
[15:38] <jml> allenap: self.assertEqual(test.test_path, test.id())
[15:38] <jml> allenap: there you go, I've written the test for you :P
[15:38] <allenap> jml: Cheers :)
[15:39] <jml> also, in random spam news, I may be entitled to receive £3750 for the accident I had. (I didn't have an accident)
[15:40] <jml> allenap: looks like a very useful change to make
[15:40] <allenap> jml: Cool. Thanks for looking at it.
[15:41] <benji> leonardr: is it ok to require that all the register_webservice elements be in the same file?
[15:45] <leonardr> benji: no, they've been split out so that every component (bugs, etc.) registers its own stuff
[15:46] <benji> leonardr: the only other thing I can think of would be to respond to the process start event (i.e., do it outside of ZCML handling)
[15:52] <leonardr> benji: can you point to some code i could copy? is the process start event a zope thing?
[15:58] <benji> leonardr: yeah, the standard Zope thing to do is to fire some events on process start so you can do startup tasks; let me find an example
[15:59] <abentley> leonardr: When I add something to IJSONRequestCache(self.request).objects, is that meant to appear in the HTML?  I don't see it, only LP.cache['context'].
[16:00] <deryck> abentley: hey.  Working on your review.  Is lib/lp/translations/templates/translation_sharing_config.pt the template you used until the sharing info page landed?  Is it used in this branch now?
[16:00] <benji> leonardr: lib/canonical/launchpad/configure.zcml line 92 has <subscriber handler=".webapp.initialization.handle_process_start" />
[16:00] <benji> ...which is implemented in lib/canonical/launchpad/webapp/initialization.py
[16:01] <abentley> deryck: yes.  Did I forget to remove it?
[16:01] <deryck> abentley: yeah, it's still showing up in the diff on the MP at least.
[16:03] <abentley> deryck: okay, removed now.
[16:03] <deryck> abentley: cool
[16:04] <leonardr> benji: ok, i'll mess around with it
[16:05] <deryck> abentley: looking at the windmill test -- can self.client.click(xpath='//*[@id="branch-incomplete-picker"]/a') be written as self.client.click(id=u"branch-incomplete-picker") and work?
[16:06] <abentley> deryck: I don't know, but don't you want to click a hyperlink rather than its surrounding div?
[16:06] <abentley> Or span, I guess.
[16:07] <deryck> abentley: I think Windmill is actually smart about this.  *I think* :-)  in other words, if it works, it's Windmill helping you and keeps you from relying on xpath.
[16:08] <deryck> or maybe it depends on the css, i.e. if the link is block and fills the div.
[16:08] <deryck> abentley: at any rate, it's a suggestion, not a requirement.  if it works, I'd use it and save the xpath.  but then you know my xpath is evil feelings. ;) :)
[16:09] <deryck> abentley: and finally for this test, the waits.forElementProperty needs to supply a timeout argument.
[16:09] <abentley> deryck: I prefer to be more precise.  If I could assign an id to the link, I'd do that.
[16:09] <deryck> abentley: ok
[16:11] <abentley> deryck: Sure.  But can we please default to suitable timeouts in the future?
[16:12] <deryck> abentley: what do you mean?  The constants aren't suitable for you?
[16:12] <abentley> deryck: No, then constants aren't the defaults.
[16:13] <deryck> abentley: I'm not following.  There are no defaults.  Windmill requires you specify this with each waits statement, no?
[16:13] <henninge> deryck: About the branch you reviewed earlier today.
[16:14] <deryck> henninge: hi. yes?
[16:14] <henninge> deryck: the tests failures I now see have their root in the fact that TranslationTemplatesCollection does not have an interface and therefore no security configuration.
[16:14] <henninge> I get lots of "Forbidden Attribute"
[16:15] <abentley> deryck: It appears that we never want the default behaviour and we're always specifying timeouts.  If so, we should fix the default behaviour to be the behaviour we usually want.
[16:15] <deryck> henninge: ah, oops
[16:15] <henninge> deryck: I could add the interface and such but the next branch will remove the need for that anyway.
[16:16] <henninge> deryck: so I'd like to leave this branch as it is now (it's gotten quite big anyway) and simply not land it.
[16:16] <henninge> The next branch will build on it and fix the issues.
[16:17] <deryck> henninge: that's sounds fine
[16:17] <henninge> cool, thanks
[16:19] <deryck> abentley: what is the "default behavior" that we don't want?  I'm sorry to be so dense here.
[16:20] <abentley> deryck: the default behaviour, according to you, is that there is no timeout.
[16:22] <deryck> abentley: right.  and that's the way windmill is designed.  There is no default value for the various wait methods.  Are you suggesting we change the windmill waits methods to include some default value?
[16:23] <abentley> deryck: yes.
[16:23] <abentley> deryck: or provide wrappers that are more suitable for us.
[16:24] <deryck> abentley: I could see providing wrappers, if that's helpful
[16:25] <abentley> I think it would be.  The best way to get people to do stuff the right way is to make the right way the easy way.
[16:27] <dpm> hey launchpadders, I'm trying to wrap up the timetable for https://wiki.ubuntu.com/UbuntuAppDeveloperWeek, and I've noticed that there are no Launchpad sessions yet. I think it would be great to have one or two to give LP more community exposure, and perhaps it would be interesting to talk about things like the integration features LP provides when developing an app, and he LP api. Has anyone got any other suggestions? Who'd be up for running a session?
[16:32] <deryck> abentley: I need to eat lunch, but will return to this after that.
[16:32] <abentley> deryck: cool.
[16:45] <leonardr> benji: which package defines the 'subscriber' directive?
[16:45] <leonardr> it's hard for me to find anything in the maze of includes
[16:48] <benji> leonardr: zope.component, src/zope/component/zcml.py has ISubscriberDirective
[16:49] <benji> and zope.component, src/zope/component/meta.zcml registers the directive
[16:53] <leonardr> thanks
[16:54] <leonardr> so i should do <include package="zope.component.meta" /> ?
[16:55] <leonardr> i think <include package="zope.component" file="meta.zcml" /> is right, but i still get unknown directive...
[16:55] <leonardr> i should have lunch and come back to this
[16:56] <benji> leonardr: yeah the second one looks right to me; it in itself may need some other directives though (probably also from zope.component)
[17:13] <dpm> jml, wold you be up for a talk during Ubuntu AppDeveloperWeek on using the Launchpad integration features when developing an application? ^^
[17:15] <jml> dpm: maybe. I'm going to try to find someone else, but will do it if I can't.
[17:17] <leonardr> jml: maybe benji could do it
[17:17] <dpm> jml, awesome, thanks. You can just add yourself or the person doing it on https://wiki.ubuntu.com/UbuntuAppDeveloperWeek/Timetable or simply ping me and I can do it for you
[17:27] <jml> dpm: yes.
[17:27] <jml> leonardr: not a bad idea.
[17:27] <jml> gotta run. will have questions later.
[17:27] <jml> bye
[17:56] <c10ud\> hello, any chance to get this fixed somehow? i'm trying to get launchpad clone my git repo, but it fails because of a submodule (which i dont need in lp, btw). here's the error: http://launchpadlibrarian.net/66911794/emesene-team-emesene-master.log
[17:56] <deryck> abentley: review is done. r=me, with minor note about variables in the js test.
[17:57] <abentley> deryck: cool.
[17:58] <c10ud\> see #400805 and #402814 they have the same issue as me.
[17:58] <_mup_> Bug #400805: Unhelpful error when importing a project with submodules <code-import> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/400805 >
[17:58] <_mup_> Bug #402814: Importing revisions with submodules is not supported <lp-code> <udd> <Bazaar:Confirmed> <Bazaar Git Plugin:Fix Released> <Launchpad itself:Triaged> < https://launchpad.net/bugs/402814 >
[17:58] <abentley> deryck: Yeah, I did not deliberately create any globals, so I'll take another pass and try to catch them all.
[17:58] <deryck> abentley: awesome, thanks.  I spotted lci and ci, I think.
[17:59] <c10ud\> err.. *2009*, can you just print a warning or whatsoever and make the import succeed? i need it for launchpad recipes...
[18:03] <abentley> deryck: yeah, and I also found "complete", "incomplete", and "link".
[18:04] <deryck> well spotted
[18:04] <abentley> deryck: any other thoughts on the code so far?
[18:05] <deryck> abentley: looks good to me.  I think most of it we went over already.  It's shaping up nicely..
[18:05] <deryck> abentley: I think it's hard to know perfectly how the rest will fit in with the other links/settings until you do it, but it looks like it should be an easy follow on for the test.
[18:06] <deryck> s/test/rest/
[18:06]  * deryck has testing stuck in the brain
[18:06] <abentley> deryck: yes, I think so.
[18:08] <abentley> deryck: I feel like at this point, I know everything I need to get stuff working, but I don't know what the usual idioms are.
[18:08] <deryck> abentley: I think you have everything you need now, too. This reads like it was written by someone who writes js regularly.
[18:09] <abentley> deryck: thanks.
[18:09] <deryck> np!
[18:10] <abentley> deryck: Do you know about the IJSONRequestCache stuff?  There's an example in bugtask.py
[18:11] <deryck> abentley: no, I don't know anything about that.
[18:12] <deryck> abentley: maybe new work from what thumper and leonardr did recently.
[18:12] <abentley> deryck: okay.  I haven't got it working yet, but it sounds promising.
[18:12] <leonardr> deryck: it's actually very old
[18:13] <deryck> ah, ok
[18:13] <abentley> deryck: it's a python-side way of getting values into the page cache, AIUI.
[18:13] <deryck> right
[18:15] <abentley> deryck: and presumably it would also be able to get that as a pure json response, though that may not yet be implemented.
[18:21] <lifeless> sidnei: yeah, all that gary said
[18:21] <lifeless> sidnei: I agree on oops cost: the more diagnostics, the more overheads
[18:22] <sidnei> lifeless, thanks for confirming
[18:22] <abentley> leonardr: is anything I stick in IJSONRequestCache.object supposed to appear automatically, or is there something I have to do to make it show?
[18:22] <lifeless> morning all
[18:23] <leonardr> abentley: putting it in there should be enough
[18:38] <leonardr> benji: ok, i think there's just one bit of this i don't understand
[18:38] <leonardr> here's launchpad:
[18:38] <leonardr> @adapter(IDatabaseOpened)
[18:38] <leonardr> def handle_process_start(ev):
[18:38] <leonardr> where does that IDatabaseOpened come from? what should i have as the equivalent?
[18:40] <benji> leonardr: that's the interface you're subscribing to; that one may work for you or there may be one that feels more like "the process is starting" than IDatabaseOpened, let me look
[18:42] <benji> leonardr: IProcessStarting looks to be the one you want
[18:43] <leonardr> benji: hm, looks like i need to add zope.processlifetime as a dependency
[18:44] <benji> yep, that's where those guys live; it's essentially a one file package
[18:47] <abentley> leonardr: it's not working.  failing test: test_cache_foo http://pastebin.ubuntu.com/583453/
[18:53] <abentley> leonardr: hmm, perhaps it only works with logged-in users?
[19:01] <leonardr> abentley: it should work if you have permission to see the object
[19:01] <abentley> leonardr: the code is wrapped with condition="view/user|nothing"
[19:03] <leonardr> abentley: possibly because the only link up to this point has been the 'me' link
[19:05] <leonardr> abentley: i think we should un-guard that zcml and make it not print a link if the object is none
[19:07] <leonardr> which file is that condition= in?
[19:07] <abentley> leonardr: Only for the links array?  Okay, but why special-case None?
[19:07] <abentley> leonardr: lib/lp/app/templates/base-layout-macros.pt
[19:08] <lifeless> leonardr: hi, when you're finished with abentley, I'd like to learn a bit about the representation cache (where does it live, is it shared between appservers, that sort of thing)
[19:09] <leonardr> lifeless: the representation cache is disabled because it turned out not to save us much time
[19:09] <lifeless> leonardr: ah, ok
[19:09] <leonardr> when it's turned on, i believe it lives in memcached
[19:09] <lifeless> leonardr: great, thanks! thats all I needed :)
[19:12] <leonardr> abentley: ok, i think the condition there is not to stop a crash when there is no me link, but to save time rendering the page for anonymous users
[19:12] <leonardr> let's suppose we want to change that, and always display the links
[19:12] <leonardr> in that case we would take out the conditional from the tal:cache tag, and  add one to the <script> tag
[19:13] <leonardr> the new conditional would omit the <script> tag if $key was None
[19:13] <leonardr> does that make sense?
[19:14] <leonardr> or, if $key is None, we can print 'null' instead of fmt:api_url
[19:14] <abentley> leonardr: Yes, that makes sense.
[19:30] <leonardr> benji: the IProcessStarting event never seems to happen, either in my tests or when i start up launchpad for real
[19:31] <benji> leonardr: hmm, I wonder if that's why LP was using IDatabaseOpened (or whatever it was)
[19:31] <leonardr> i'll try the other event
[19:33] <leonardr> benji: the other event isn't firing either! here's my zcml
[19:33] <benji> leonardr: I grepped for IProcessStarting and found it in several places in LP
[19:33] <leonardr> oh, wait
[19:33] <leonardr> my zcml is obviously dumb
[19:34] <benji> :)
[19:37] <leonardr> benji: same result with non-dumb zcml:
[19:37] <leonardr>     <subscriber
[19:37] <leonardr>     handler="lazr.restful.metazcml.webservice_sanity_checks"
[19:37] <leonardr>     for="zope.processlifetime.IProcessStarting"/>
[19:38] <benji> leonardr: try using the event interface: IProcessStartingEvent
[19:39] <leonardr> ah
[19:40]  * benji tries to remember why both exist.
[19:41] <bac> hi sinzui, i've got a question about DistributionSourcePackage
[19:41] <bac> sinzui: it is marked as being an IStructuralSubscriptionTarget ... but i cannot find where that is supported in the UI.  you know anything about it?
[19:42] <leonardr> benji: no difference
[19:42] <benji> leonardr: I don't think that'll make a difference, IProcessStartingEvent is just a backward-compatible name for...
[19:42] <benji> right
[19:43] <benji> leonardr: how are you starting the process? the events sure do seem to work, that or we spend a lot of time wiring up subscribers for them that don't do anything: lib/canonical/launchpad/webapp/configure.zcml
[19:44] <leonardr> benji: i am running 'make run'
[19:44] <benji> that's simple enough
[19:46] <benji> leonardr: I just put a pdb in one of LP's IProcessStarting handlers and did make run and got a pdb prompt
[19:50] <leonardr> argh
[19:50] <leonardr> i can't think about this anymore, i need to come back to it later
[19:50] <leonardr> benji: is this something i could punt over to you? do you have time?
[19:51] <benji> leonardr: sure, I have time to take a couple of swings at it
[19:51] <leonardr> benji: ok...
[19:55] <leonardr> benji: lp:~leonardr/lazr.restful/integrate-strict-versioning
[19:55] <benji> looking
[19:55] <leonardr> you're trying to make metazcml.py#webservice_sanity_checks() run
[20:03] <lifeless> flacoste: what time is our call?
[20:03] <flacoste> lifeless: now according to my calendar, but according to URC it's in 1h, i can do either
[20:04] <lifeless> now is fine :)
[20:04] <flacoste> s/URC/UTC/
[20:04] <flacoste> let's talk now then
[20:04] <leonardr> wallyworld_, are you around for a quick standup? i have to leave pretty soon for an appointment
[20:10] <lifeless> https://code.launchpad.net/~lifeless/storm/with/+merge/52630
[20:21] <benji> leonardr: is there a test that I can run or do I need to get an LP instance to use this version of lazr.restful?
[20:22] <leonardr> benji: i don't know whether it should be running during any of the existing tests, but it's not
[20:22] <leonardr> i'm sure it should be running during lp startup, and it's not
[20:22] <leonardr> so i recommend working in an lp context
[20:22] <benji> ok
[20:22] <leonardr> i have to go to an appointment, but i'll stay online in case you find anything
[20:41] <benji> leonardr-afk: the problem was that LP doesn't use lazr/restful/basic-site.zcml; I put the handler registration in lazr/restful/configure.zcml (which LP does use) and bin/run drops me into pdb
[20:43] <wallyworld_> gary_poster: are you still online? I have a zope question
[20:43] <gary_poster> wallyworld, fire away.  benji is great for this stuff too, fwiw.
[20:45] <wallyworld_> gary_poster: thanks. i am writing a test and want to hook up an object modified event listener for object modification. afaict, these are not invoked when tests are run. i have some code, but it doesn't work. i'll pastebin the code
[20:46] <gary_poster> wallyworld_, it depends on what is set up.  zope.event.notify is always called
[20:46] <gary_poster> that is a wildly simple function
[20:46] <wallyworld_> https://pastebin.canonical.com/44984/
[20:46] <gary_poster> usually we have zope.component register a handler in zope.event
[20:47] <gary_poster> which does the whole dispatch-by-classes-or-interfaces thing
[20:47] <gary_poster> looking...
[20:47] <wallyworld_> gary_poster: from what i can see, the this listener is not invoked in tests:
[20:47] <wallyworld_>     <subscriber
[20:47] <wallyworld_>         for="lp.bugs.interfaces.bugtask.IBugTask                 lazr.lifecycle.interfaces.IObjectModifiedEvent"
[20:47] <wallyworld_>         handler="lp.bugs.subscribers.bugtask.notify_bugtask_edited"/>
[20:48] <gary_poster> wallyworld_, is this being run in a layer, or with some other kind of setup that sets zope.component up?  I suspect the first part (layer) is the most likely approach.  If you are not running in any layer and you don't have any special setup, that's probably the story
[20:49] <wallyworld_> gary_poster:  i'm using layer=DatabaseFunctionalLayer
[20:49] <wallyworld_> gary_poster: from what i can see from other usages of TestEventListener, this is sufficient
[20:50] <gary_poster> I don't remember what layer does what, but I'd expect that to work.
[20:50]  * gary_poster looking at code again
[20:50] <gary_poster> yours, that is
[20:50] <wallyworld_> TestEventListener comes from canonical.lazr.testing
[20:51] <wallyworld_> gary_poster: i'd also be happy if i could make the actual event listener fire during the test ie notify_bugtask_edited
[20:52] <gary_poster> I figured :-)
[20:52] <jml> wallyworld_: are you importing zope.component.event?
[20:52]  * wallyworld_ looks
[20:52] <gary_poster> sadly, my brain juice has dropped to precipitously low levels...
[20:52] <jml> wallyworld_: you have to import it to make zope event->adapter stuff work
[20:53] <jml> it's bit me and others before.
[20:53] <wallyworld_> jml: not importing that.
[20:53] <gary_poster> that's the hook I was talking about, yeah.
[20:53] <gary_poster> I'd expect DatabaseFunctionalLayer to import that
[20:53] <wallyworld_> jml: will try that. if that's the solution, thanks * 1000
[20:53] <gary_poster> if it does not, you should perhaps choose another layer
[20:53] <jml> gary_poster: yeah. or FunctionalLayer.
[20:53] <jml> gary_poster: the problem is that it can also bite production scripts
[20:54] <wallyworld_> gary_poster: i've tried a few layers
[20:54] <jml> (as it did memorably for the branch scanner at one point)
[20:54] <gary_poster> because by doing that you are changing the environment for all subsequent tests
[20:54] <wallyworld_> jml: DatabaseFunctionalLayer extends Functional layer so it should make no difference?
[20:54] <gary_poster> and thus hiding problems for other people, possibly
[20:54] <gary_poster> I'd try AppLayer as a smoke test
[20:54] <jml> wallyworld_: not practically, it's just more appropriate. FunctionalLayer sets up all the Zope stuff.
[20:55] <gary_poster> Well
[20:55] <jml> wallyworld_: but at this point, the importing doesn't take place in any layer
[20:55] <gary_poster> I guess I'd try what jml suggested as a smoke test
[20:55] <jml> # This non-standard import is necessary to hook up the event system.
[20:55] <jml> import zope.component.event
[20:55] <gary_poster> no layer: yuck :-/
[20:55] <wallyworld_> gary_poster: i'm doing this in a separate, new test class
[20:55] <jml> wallyworld_: do the import. see if it works.
[20:55] <wallyworld_> i've tried AppServerLayer
[20:55] <jml> wallyworld_: layers are a red herring for now.
[20:55] <wallyworld_> will do. trying now
[20:55] <gary_poster> wallyworld_, the change is in global state
[20:56] <gary_poster> jml, well, not a red herring for the proper fix IMO
[20:56] <jml> (incidentally, I always hear that as "hewwing" when typed)
[20:56] <gary_poster> heh
[20:56] <jml> gary_poster: yeah. I guess ideally FLayer would set up the hook manually and then remove the hook when done.
[20:56] <gary_poster> either that or have our code always set up the hook ourselves
[20:57] <jml> hmm.
[20:57] <jml> that's not a bad idea either.
[20:57] <gary_poster> but putting it in a test setup is a bad idea
[20:57] <gary_poster> well
[20:57] <jml> although, it's got to be undoable
[20:57] <gary_poster> not the best idea :-)
[20:57] <jml> (as in, reversible)
[20:57] <gary_poster> why do we need to reverse it?  no challenge, just no idea
[20:57]  * wallyworld_ waits for disk to stop thrashing so test can run
[20:57]  * gary_poster is also feeling very sleepy :-/
[20:57] <jml> e.g. our logging code does some useful set up, but then it makes subsequent tests print stuff to stderr uncontrollably
[20:58] <jml> because it mutates global state
[20:58] <gary_poster> ah-ish
[20:58] <gary_poster> well, if the global state is our expected underlying state then that's OK it seems to me
[20:58] <gary_poster> mutating the global state after it has been set up is the bug bear
[20:59] <jml> we have a non-trivial amount of code that doesn't use the site.zcml or exec_zcml_for_scripts
[20:59] <jml> obviously it's the minority, but still
[20:59] <gary_poster> if importing the module is idempotent it still seems not so bad
[20:59] <gary_poster> but eh
[20:59] <jml> indeed :)
[21:00] <jml> I just got from training. time for a shower before my call w/ huwshimi
[21:01] <gary_poster> I'm not usually one to run away at the sound of the factory bell, but I'm feeling pretty zoned.
[21:01] <gary_poster> bye
[21:02] <gary_poster> wallyworld_ are you set for now?
[21:03] <wallyworld_> gary_poster: just finished rerunning test. no good but i'll keep looking. thanks for helping
[21:03] <lifeless> flacoste: https://devpad.canonical.com/~lpqateam/ppr/lpnet/2011-03/daily_2011-03-14_2011-03-15/
[21:03] <gary_poster> benji, you happen to have brain juice left to help wallyworld_?
[21:03] <lifeless> flacoste: https://devpad.canonical.com/~lpqateam/ppr/lpnet/2011-03/daily_2011-03-16_2011-03-17/
[21:06] <flacoste> lifeless: https://wiki.canonical.com/InformationInfrastructure/Review-LL-20110317
[21:10] <benji> wallyworld_: what's up? (not much brain juice left here either, got a bit of a headache)
[21:11] <wallyworld_> benji: i am trying to hook up an event listener in a test to be invoked when an object is modified, but i can't get it to be called
[21:12] <wallyworld_> benji:
[21:12] <wallyworld_>   https://pastebin.canonical.com/44984/
[21:13] <benji> have you double-checked that the ObjectModified event is being fired?  is there another handler you can put a pdb in to check?
[21:13] <wallyworld_> i an using TestEventListener. jml suggested that i needed to import zope.component.event but that didn't help in my case
[21:14] <wallyworld_> benji: i'm not sure how to check that it is being fired. if i could get the actual notify_bugtask_edited listener to fire during the test, i would need to hook up a fake one
[21:15] <wallyworld_> wouldn't
[21:15] <wallyworld_> benji: it's eod for you so if your batteries are dead, that's ok, i'll try a few other things
[21:17] <benji> wallyworld_: ok, a few parting shots: I don't know why the event wouldn't be fired in a test; you can put a PDB in zope.event.notify to see when events get fired (and you can enjoy the beauty that is the implementation of zope.event)
[21:18] <wallyworld_> benji: will do. thanks.
[21:31] <jml> huwshimi: hello
[21:31] <huwshimi> jml: Morning
[21:31] <jml> huwshimi: skype?
[21:31] <huwshimi> jml: Indeed
[21:40] <lifeless> jml: Want to catch up sometime this week?
[21:41] <jml> lifeless: yes, but it might be tricky to find the time. Will get in touch when I'm off the phone.
[21:41] <lifeless> jml: kk
[21:49] <lifeless> wgrant: oem no longer use buildd-secret
[21:49] <wgrant> lifeless: That was less slow than I expected.
[21:49] <wgrant> Excellent.
[22:08] <lifeless> flacoste: you has mail
[22:12] <wgrant> lifeless: Are you going to QA your branches thing?
[22:13] <lifeless> wgrant: I did
[22:13] <lifeless> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/files/head:/lib/lp/blueprints/model/specification.py is breaking for me
[22:13] <lifeless> oh, the next one
[22:14] <lifeless> sure, doing now - was on phone etc earlier didn't see the notification
[22:14] <lifeless> frell, that was snappy
[22:23] <jml> lifeless: my morning would be easier for me. evenings are kind of packed atm.
[22:24] <lifeless> jml: I am generally up late tuesday
[22:24] <lifeless> jml: would you like to talk tomorrow morning?
[22:24] <jml> lifeless: sure.
[22:24] <lifeless> lets do that
[22:25] <jml> lifeless: 0900UTC ok?
[22:25] <jml> lifeless: alternatively, I could do after the TL call, but I'll be on a bus.
[22:27] <lifeless> its currently UTC 2230 ?
[22:27] <lifeless> so in 10h30m ?
[22:27] <jml> lifeless: yes.
[22:27] <lifeless> that makes it 10pm here - sure, can do.
[22:27] <jml> lifeless: ok.
[22:28] <jml> lifeless: also, in case it helps, the UK moves to summer time this Sunday.
[22:28] <lifeless> \o/ confusion
[22:28] <jml> yeah.
[22:28] <lifeless> I blame NZ for this whole disaster
[22:31] <lifeless> ok, time for another timeout fix
[22:33] <wgrant> lifeless: We have to look for "ever published" :(
[22:33] <wgrant> lifeless: Because it's reasonable to file bugs on removed pacakgse.
[22:34] <lifeless> is it?
[22:36] <wgrant> For SRUs.
[22:36] <lifeless> series specific
[22:36] <wgrant> Until we can file directly on series, we can't forbid filing on the distribution.
[22:36] <lifeless> so there is a conflict in requirements
[22:37] <wgrant> A conflict in present requirements, or a conflict in requirements 5 years ago and now?
[22:37] <lifeless> shrug, will think about it more when we finish with our critical bugs
[22:37] <lifeless> wgrant: probably resolvable, definitely has a temporal component
[22:38] <lifeless> 5 seconds - https://bugs.launchpad.net/ubuntu/+bugtarget-portlet-bugfilters-stats
[22:38] <lifeless> \o/
[22:38] <wgrant> Excellent.
[22:40] <lifeless> 5 seconds to render https://code.launchpad.net/~bryce/launchpad/lp-617698-forwarding/+merge/41003/+index
[22:43] <lifeless> sinzui: is the person merge job configure to run ?
[22:47] <lifeless> is anyone on the db-devel conflict?
[22:49] <wgrant> lifeless: It's not already fixed?
[22:49] <sinzui> I am
[22:49] <lifeless> sinzui: cool, thanks
[22:49] <sinzui> It was a little awkward but make schema says I am done
[22:49] <lifeless> jcsackett: btw - bug 727023 needs some more examination
[22:49] <_mup_> Bug #727023: Cve:+index timeouts <qa-ok> <timeout> <Launchpad itself:Triaged by jcsackett> < https://launchpad.net/bugs/727023 >
[22:49] <wgrant> Huh, why is it not still spamming us, then?
[22:51] <sinzui> lifeless: the merge-person-job is not configured to run. Nothing uses it yet
[22:52] <lifeless> https://code.launchpad.net/~openerp-commiter/openobject-addons/trunk-extra-addons/+merge/6722/+index makes me sad - 312 queries
[22:52] <lifeless> sinzui: we just deployed your commit to make things use it
[22:52] <lifeless> sinzui: or is it still guarded in some fashion?
[22:53] <sinzui> The ui does not use it. I just started that branch. My lat branch lets us query the state and fixed the db permission exposed when I constructed a sane test
[22:54] <lifeless> sinzui: I'm talking about bug 728471
[22:54] <_mup_> Bug #728471: Person:+delete timeouts : Add sanity checks to mergeAsync <merge-deactivate> <qa-ok> <timeout> <Launchpad itself:Fix Released by sinzui> < https://launchpad.net/bugs/728471 >
[22:54] <lifeless> sinzui: if that helps explain my confusion
[22:55] <lifeless> its so nice seeing bug pages render in < 2 seconds.
[22:55] <lifeless> need to get that to < 1 second though
[22:56] <sinzui> lifeless: sorry. look like I reversed the description of the bug I split
[22:57] <lifeless> sinzui: heh, that would explain it
[22:59] <sinzui> lifeless: I fixed the description to https://bugs.launchpad.net/launchpad/+bug/728471 That is what I tested for release
[22:59] <_mup_> Bug #728471: Person:+delete timeouts : Add sanity checks to mergeAsync <merge-deactivate> <qa-ok> <timeout> <Launchpad itself:In Progress by sinzui> < https://launchpad.net/bugs/728471 >
[22:59] <lifeless> sinzui: thanks