[00:34] <poolie> wallyworld: bug 1342, whoa :)
[00:34] <_mup_> Bug #1342: Can't delete spurious "Affects" lines (bugtasks) from bug reports <canonical-losa-lp> <lp-bugs> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/1342 >
[00:34] <wallyworld> poolie: are you happy or sad?
[00:34] <poolie> happy and impressed
[00:35] <wallyworld> happy yes, there's nothing to be impressed about
[00:35] <poolie> i would like if you qa http://launchpad.net/bugs/861979 some time so my oops fix can have a go at production
[00:35] <_mup_> Bug #861979: utf-8 encode diffs attached to outgoing email <qa-needstesting> <Launchpad itself:Fix Committed by wallyworld> < https://launchpad.net/bugs/861979 >
[00:35] <wallyworld> poolie: doing it now but it's being difficult
[00:35] <poolie> because not enough of that stuff works easily on qas?
[00:35] <wallyworld> branch scan job oopsed
[00:35] <StevenK> poolie: We can't deploy until Monday at least.
[01:02] <lifeless> wallyworld: hey
[01:03] <lifeless> wallyworld: whats the implementation strategy you guys are planning for bug 1342 ?
[01:03] <wallyworld> lifeless: hello
[01:03] <_mup_> Bug #1342: Can't delete spurious "Affects" lines (bugtasks) from bug reports <canonical-losa-lp> <lp-bugs> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/1342 >
[01:03] <StevenK> lifeless: Magic
[01:03] <lifeless> StevenK: sadly, I'm too jaded to consider that a great answer ;)
[01:03] <wallyworld> lifeless: log activity and delete unless it is the last task on a bug
[01:04] <wallyworld> do it via api initially
[01:04] <StevenK> That isn't what lifeless meant.
[01:04] <StevenK> And blocked via flag
[01:04] <wallyworld> yes
[01:04] <StevenK> Personally, I'm picturing IBugTask.remove()
[01:05] <lifeless> probably wants to be on Bug, but I'll let you guys figure that out
[01:05] <wallyworld> i haven't looked yet. doing qa and other administrivia
[01:05] <lifeless> wallyworld: things to watch out for - conjoined masters will make 'last task on a bug' hard to determine
[01:05] <wallyworld> hmmm
[01:06] <StevenK> Conjoinness rises its ugly head to bite us in the ass again
[01:06] <wallyworld> dumb question - what exactly is a conjoined master?
[01:06] <lifeless> wallyworld: will notifications be sent to the context the task is removed from ?
[01:06] <wallyworld> lifeless: i expect so
[01:06] <lifeless> wallyworld: your team can help you on the conjoined master thing :) - I mention it because its not obvious until you're in the trenches.
[01:06] <StevenK> wallyworld: BugTask for Ubuntu, and then it's nominated for natty
[01:07]  * wallyworld needs to buy some gum boots
[01:07] <lifeless> wallyworld: I think they should; as there isn't a LEP, I'm using this forum here to toss some constraints your way :)
[01:07] <lifeless> StevenK: uhm, no. :) thats not a conjoined master
[01:07] <StevenK> Oh
[01:07] <StevenK> lifeless: I don't like it on IBug -- I prefer the idea of grabbing IBug.tasks, grabbing the one you want and calling .remove() or .delete() on it
[01:08] <lifeless> StevenK: wallyworld: when you create a task for a *pillar directly* one task is made. If you also create a task for that pillars *development focus*, then those two tasks are shown as one in the Web UI, and are together a 'conjoined master'
[01:08] <lifeless> StevenK: sometimes that will delete two tasks.
[01:08] <wgrant> Why would it delete two tasks?
[01:08] <lifeless> StevenK: so while you like the idea, I think it will be harder to code and harder to get right, if you put it on BugTask. Just saying.
[01:08] <lifeless> wgrant: again, conjoined masters.
[01:08] <wgrant> We don't have to continue treating them as conjoined for deletion.
[01:08] <lifeless> wgrant: I will wait for a second while you headdesk.
[01:09] <lifeless> wgrant: we have to show the difference in the UI then...
[01:09] <wgrant> Delete one of the two, and it is magically not conjoined any more.
[01:09] <wgrant> Magical!
[01:09] <lifeless> wgrant: unless you delete the non-series task.
[01:09] <wgrant> And?
[01:09] <wgrant> There's no longer a conjoined slave.
[01:09] <wgrant> No problem.
[01:09] <lifeless> its not a valid state to have a series task with no non-series master
[01:10] <wgrant> Isn't it?
[01:10] <wgrant> I thought you argued a couple of months ago that it was.
[01:10] <wgrant> When I was attempting to restrict it during my retargeting work.
[01:10] <wgrant> I'm pretty sure we permit it now.
[01:11] <wallyworld> does the BugTaskSearch code have explicit code for dealing with conjoined masters?
[01:11] <wgrant> Even if we want to forbid it, it's not directly related to conjoinment.
[01:11] <wgrant> *Any* series task is affected.
[01:11] <wgrant> Conjoinment is unspecial.
[01:11] <lifeless> I argued that we have such states already, and that the conjoined thing messy, and that we shouldn't make it worse by breaking existing things
[01:11] <lifeless> wgrant: thats true
[01:11] <lifeless> wgrant: So let me phrase this differently: delete shouldn't let users create a state that they cannot already create.
[01:12] <wgrant> Certainly.
[01:12] <lifeless> Its my understanding that you cannot create a series task w/o a non-series same-pillar task, today.
[01:12] <lifeless> (via web UI)
[01:13] <lifeless> anyhow, long story short: beware the jabberwocky; send notifications to the folk the task was removed from; log enough that someone can undo brain damage; think about who can delete (the person who added it, the owner of the context, who else?) carefully. Have fun!
[01:13] <wallyworld> if the two tasks are shown as one in the web ui, if someone changes the assignee etc, which task gets updated?
[01:14] <lifeless> wallyworld: both
[01:14] <wgrant> lifeless: https://bugs.qastaging.launchpad.net/ubuntu/+bug/1234
[01:14] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[01:14] <wallyworld> why do we need two task then?
[01:15] <lifeless> wallyworld: the idea is that when a task nominated for the development focus is closed, its closed for the project as a whole too (in the absence of older series tasks)
[01:15] <lifeless> wallyworld: the current implementation is just that, an implementation.
[01:15] <lifeless> wallyworld: I would like to get rid of non-series tasks
[01:15] <wgrant> lifeless: As for permissions, we agreed that bug supervisor + task creator is probably sensible.
[01:16] <lifeless> wgrant: I'd suggest owner of the original task context, but that way lies madness
[01:16] <wgrant> lifeless: Never let me hear you use the phrase "original task" again :)
[01:22] <lifeless> sinzui: ping
[01:27] <lifeless> feeling better?
[01:37] <stub> me? mostly.
[01:37] <StevenK> lifeless: You are a BAD MAN
[01:37] <StevenK> BAD!
[01:38] <stub> Been crook a few days. Yesterday it had mutated into a head cold but that seems to have cleared up now.
[01:41] <lifeless> stub: ugh. Glad you're better :)
[01:41] <stub> Just in time to be flooded tomorrow :-)
[01:41] <lifeless> StevenK: getting things done in a tolerable fashion isn't bad. Cody can do that work unless it actually has holes in it.
[01:42] <StevenK> lifeless: I don't think it's tolarable, I think it's a terrble hack
[01:42] <StevenK> IPerson is already too fricken big
[01:42] <StevenK> And advocating a celebrity?
[01:42] <lifeless> StevenK: what are the consequences of it that make it intolerable ?
[01:42] <StevenK> We want LESS celebrites, not more.
[01:43] <StevenK> lifeless: That we are stuck maintaining it
[01:43] <lifeless> until someone creates a launchpad-itself model object that such policy objects can link to, we need celebs
[01:43] <StevenK> Cody or Tim drive it by and say "Excellent, the LP security model is out of our way, thanks" and we're stuck with the baby
[01:43] <wgrant> There is also the issue of non-virt builders.
[01:43] <StevenK> So, I object.
[01:44] <wgrant> Ideally this would only grant them access to their own little world of fake-virt armel.
[01:44] <lifeless> StevenK: you're rather they web scraped ?
[01:44] <wgrant> lifeless: Web scraping is always better, because it's not an interface that we have to support.
[01:44] <lifeless> wgrant: I'm not sure how to do that without deeper plumbing work; I was aiming to limit the scope of the permissions rather than rework
[01:44] <wgrant> :)
[01:45] <StevenK> lifeless: I'd rather we give them a restricted account with the privs they want, rather than other madness
[01:45] <StevenK> But no one listens to me anyway, so meh
[01:45] <lifeless> StevenK: this gives them a restricted account with the privs they want
[01:45] <lifeless> StevenK: *I* listen to you - do you have a proposal on how that would work, and how does it compare in dev + maintenance effort to the other proposals ?
[01:46] <wgrant> I wonder how close the secure panda cluster is.
[01:46] <lifeless> stub: bug indices at 98% bloat :)
[01:46] <wgrant> That would make this easier.
[01:46] <stub> awesome
[01:46] <elmo> time to try pg_reorg? :)
[01:46] <elmo> oh, it's an index
[01:46] <elmo> I'll shutup now
[01:47] <lifeless> elmo: :)
[01:47] <lifeless> elmo: aieeeeeeeeeee
[01:47] <elmo> haha
[01:47] <stub> https://code.launchpad.net/~stub/launchpad/replication/+merge/78914 has landed, but the scanner hasn't flagged it as merged.
[01:47] <elmo> hahaha
[01:47] <elmo> lifeless just googled pg_reorg
[01:47] <wgrant> stub: db-devel vs devel
[01:48] <stub> pg_reorg is for wimps.
[01:48] <StevenK> I just did, that's *insane*
[01:48] <wgrant> Oh, it landed on devel.
[01:48] <stub> wgrant: nah...
[01:48] <wgrant> Nevermind me then, something's just screwed.
[01:48] <wgrant> Ah.
[01:48] <stub> Will it have been logged somewhere? I'm not fussed but not sure if it should be raised somewhere.
[01:48] <wgrant> https://code.launchpad.net/~stub/launchpad/replication
[01:48] <wgrant> Ancient branch.
[01:48] <wgrant> The scan probably timed out.
[01:49] <mwhudson> pg_reorg is that thing you use when you write to your database too much for vacuum to work right?
[01:49] <wgrant> Because our branch scanner is fast and awesome and reliable and perfect.
[01:49] <mwhudson> (and want to die in a fire)
[01:49] <stub> All my branches are ancient ;)
[01:49] <wgrant> stub: Well, crucially, this one is missing 18 months of revisions.
[01:49] <StevenK> Hah
[01:50] <wgrant> Ahh
[01:50] <wgrant> And the old scan is based on db-devel
[01:50] <wgrant> The new one is probably devel.
[01:50] <wgrant> So it has to rewrite tonnes.
[01:50] <stub> I just crapped on https://code.launchpad.net/~allenap/launchpad/oneiric-librarian-bug-871596/+merge/79175 . Anyone disagree that this is a Storm bug and better to address there?
[01:51] <wgrant> stub: Agreed.
[01:51] <wgrant> That seems to pretty clearly be a DisconnectionError.
[01:51] <lifeless> +1
[01:53] <StevenK> lifeless: Oh, I noticed this yesterday:
[01:53] <StevenK> steven@liquified:~/launchpad/lp-branches/devel% head -n 1 LICENSE
[01:53] <StevenK> Launchpad is Copyright 2004-2009 Canonical Ltd.
[01:53] <lifeless> yes, copyright overheads are a PITA
[01:53] <StevenK> lifeless: Should I JFDI the fix?
[01:54] <lifeless> yeah
[01:54] <lifeless> cron it for the 1/1/*
[01:54] <StevenK> On my desktop? Not likely :-P
[03:05] <StevenK> "But Robert tells us that the problematic team membership records are harder to clean up than regular old requests."
[03:05] <StevenK> Clearly, both jtv and I are missing something.
[03:07] <lifeless> ECONTEXT
[03:09] <lifeless> wallyworld: \o/ at ajax batching
[03:10] <wallyworld> lifeless: seems to work well. if we get sorting solved, we can add it to the bug and blueprints tables on the milestones page
[03:10] <wallyworld> there's already a half done branch for that
[03:11] <lifeless> whats the sorting issue?
[03:11] <wallyworld> when sortable.js is used for client side sorting, it doesn;t make sense if only a batch of results is rendered
[03:11] <lifeless> well, thats what we do today right ?
[03:12] <wallyworld> the sorting doesn;t break, but it only sorts the current batch
[03:12] <lifeless> how does avoiding page-loads make it worse?
[03:12] <wallyworld> yes but today for those tables there's no batching
[03:12] <lifeless> oh, I see.
[03:12] <wallyworld> so the sort works on the entire results set
[03:12] <lifeless> yes
[03:12] <wallyworld> so we need to catch the table header click and send a new query to the back end
[03:12] <lifeless> can I make two suggestions
[03:13] <wallyworld> sure
[03:13] <lifeless> rather than replacing the batch, consider - at least as an option - *appending* to it.
[03:13] <lifeless> (and scroll down to the new bits)
[03:14] <wallyworld> lifeless: otp just a sec
[03:14] <lifeless> I suspect, much of the time, that that would be closer to what users want
[03:14] <lifeless> wallyworld: np
[03:18] <lifeless> -> picking up lynne
[03:19] <wallyworld> lifeless: will ping you later
[03:56] <StevenK> wgrant: Hai
[03:56] <nigelb> *yawn* Morning
[03:57] <wgrant> StevenK: Hello.
[03:57] <StevenK> wgrant: I have a test, but I want to see that it creates an OOPS.
[03:57] <wgrant> getLastOopsReport?
[03:58] <wgrant> Or self.oopses perhaps.
[03:58] <wgrant> Depending on how you do it.
[04:02] <StevenK> Traceback (most recent call last):\nMixedVisibilityError\n
[04:02] <StevenK> I am disappoint.
[04:03] <StevenK> So I guess I need to inject a traceback into my raising() call
[04:12] <lifeless> StevenK: no, if you do thats a bug somewhere else
[04:12] <lifeless> StevenK: is it in a subprocess?
[04:12] <lifeless> StevenK: if not, self.oopses is the thing to use.
[04:13] <StevenK> lifeless: self.oopses looks good, but I want the full traceback
[04:14] <lifeless> StevenK: it should be there
[04:14] <lifeless> StevenK: if its not, something is mangling it
[04:14] <lifeless> StevenK: report['tb_text'] should have it
[04:15] <StevenK> 'tb_text': 'Traceback (most recent call last):\nMixedVisibilityError\n'
[04:15] <lifeless> StevenK: as I said, something is mangling it
[04:15] <StevenK> getUtility(IErrorReportingUtility).raising(
[04:15] <StevenK>                 (MixedVisibilityError, MixedVisibilityError(), None),
[04:15] <StevenK>                 request)
[04:16] <StevenK> That's how I'm raising it, perhaps that is wrong
[04:16] <lifeless> uhm, lets start over. What are you trying to do ?
[04:16] <StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/soft-oops-on-private-team-disclosure/+merge/79066
[04:16] <lifeless> there are no soft oopses
[04:16] <wgrant> There are no *informational* OOPSes.
[04:16] <wgrant> There can certainly be soft ones.
[04:18] <lifeless> this has the potential to cause thousands of oopses
[04:18] <lifeless> are you sure you want to do it ?
[04:18] <lifeless> (for instance, an api collection with 75 members in it will be trimmed by lazr, and that one web API call will generate 75 oopses)
[04:18] <lifeless> oh, and I see that you won't log from the API, which is good on one hand, but means you won't see it on the other
[04:18] <lifeless> .
[04:18] <lifeless> bloody ISP
[04:18] <StevenK> lifeless: So, we want to turn this on for an hour or so and then see what happened
[04:19] <StevenK> This is not a feature flag to leave enabled for too long
[04:19] <StevenK> And it is purely for data gathering
[04:19] <StevenK> So we can nail down the prime suspects, as it were
[04:19] <lifeless> ok
[04:19] <lifeless> so you actually need an *exception*:
[04:19] <lifeless> try:
[04:19] <lifeless>  raise MixedVisibilityError('some text here')
[04:19] <StevenK> I don't want to stop it
[04:20] <lifeless> except MixedVisibilityError:
[04:20] <StevenK> I just want to log it
[04:20] <lifeless>  ...raising()
[04:20] <lifeless> StevenK: have faith that I understand your use case :)
[04:21] <StevenK> try raise except results in 'tb_text': 'Traceback (most recent call last):\nMixedVisibilityError\n'
[04:23] <lifeless> paste the updated code ?
[04:23] <StevenK> lifeless: http://pastebin.ubuntu.com/707156/
[04:24] <lifeless> StevenK: nono, don't make the tuple by hand
[04:24] <lifeless> sys.exc_info()
[04:27] <StevenK> lifeless: Which tuple, sorry?
[04:27] <StevenK> Oh, just toss sys.exc_info() rather than (MixedVi ...
[04:27] <lifeless> http://paste.ubuntu.com/707159/
[04:28] <jtv> Can someone who knows code imports help with this question?  https://answers.launchpad.net/launchpad/+question/174071
[04:28] <StevenK> lifeless: Modulo the left bracket, I just did that myself, so great minds
[04:29] <lifeless> StevenK: that should work better for you
[04:29] <StevenK> 'tb_text': 'Traceback (most recent call last):\n  Module lp.app.browser.tales, line 1327, in _report\n    raise MixedVisibilityError()\nMixedVisibilityError\n'
[04:30] <StevenK> Although I'm calling into the formatting API myself, so that should be okay.
[04:31] <StevenK> lifeless: Thanks for the help.
[04:31] <lifeless> StevenK: anytime
[04:32] <StevenK> I was expecting more frames, but I shouldn't in this case.
[04:41]  * wgrant yearns for IArchiveCollection and IPublicationCollection
[04:45] <wallyworld> lifeless: batching - you want to append the next batch to the current batch? to create a table with twice as many rows (and a scroll bar)? doesn't sound quite right to me
[04:46] <wgrant> Why not?
[04:46] <wgrant> That's how most modern batchers work.
[04:46] <wgrant> Start scrolling down, it automatically loads the next bit and extends the page.
[04:48] <wallyworld> that would be a significant rewrite of the current batcher though
[04:48] <wallyworld> well, the js etc
[04:49] <wallyworld> i was just wanting to do something backwards compatible and in line with the current implementation
[04:49] <wallyworld> at least for now
[04:50] <nigelb> WIth launchpad's move to SOA, this might be an interesting read, if you folks haven't read it already - https://plus.google.com/112678702228711889851/posts/eVeouesvaVX
[04:50] <wgrant> Yeah, that's been circulating around a bit. A rather impressive work.
[04:51] <StevenK> Indeed
[05:02] <StevenK> lifeless: Hai, Mr. OCR.
[05:03] <wallyworld> stub: has the branch transitively_private not null patch been applied to prod?
[05:13] <StevenK> wgrant, wallyworld: Do either of you want to review my logging branch?
[05:13] <wallyworld> StevenK: i'll have a look
[05:17] <wgrant> wallyworld: The NOT NULL patch is next in the DB queue.
[05:17] <wgrant> wallyworld: Will probably be deployed on Monday, unless oneiric breaks stuff.
[05:17] <wallyworld> ok
[05:17] <wallyworld> just curious
[05:18] <wgrant> The last few windows have been used for oneiric-critical cocoplum deployments, unfortunately.
[05:18] <wallyworld> StevenK: the method _report() - could it have a better name, like _report_visibility_leak() or something
[05:19] <StevenK> wallyworld: I like the _ since it is internal, and I doubt it will remain there for long
[05:19] <wallyworld> StevenK: it's not the _, but the name
[05:19] <wallyworld> report
[05:19] <wallyworld> vs report_visibility_leak
[05:19] <StevenK> Yes, alright
[05:19] <wallyworld> sorry
[05:20] <StevenK> :%s/\(_report\)/\1_visibility_leak/
[05:20] <StevenK> Fixed
[05:21] <wallyworld> StevenK: i also think the test should ensure the ooops content is related to the mixed visbility error raised
[05:21] <wallyworld> at the moment, there's nothing to test that the oops is informational or is related to the error we are raising
[05:21] <wallyworld> it could be any oops
[05:22] <wallyworld> and we wouldn't know
[05:22] <StevenK>             self.assertTrue(
[05:22] <StevenK>                 'MixedVisibilityError' in self.oops[0]['tb_text'])
[05:22] <StevenK> Rather than what is there, okay?
[05:22] <wallyworld> i think that works. is there a way to tell that it's a soft oops?
[05:23] <StevenK> That the call returns u'<hidden>', which I already test.
[05:23] <wallyworld> ah ok, since a hard oops would not return a result
[05:23] <wallyworld> it would just error out
[05:23] <StevenK> Exactly.
[05:24] <wallyworld> cool. thanks for making the changes. r=me
[05:30] <lifeless> wallyworld: its a desired feature, even though it is different to the non-js batch
[05:30] <lifeless> wallyworld: non-js batch being the same as js-batch isn't a goal in and of itself :)
[05:30] <lifeless> wallyworld: if you don't have time, thats fine. Consider though that the bugtask comment js batch works this way ;)
[05:30] <wallyworld> lifeless: sure. i'm just doing a bit at a time - small chunks of improvement
[05:31] <wallyworld> it was just a coding spike rather than a proper part of disclosure
[05:31] <lifeless> ah cool
[05:31] <lifeless> I think its great.
[05:32] <lifeless> just tossing out nice to haves ;)
[05:32] <wallyworld> for what it is it works. backwrads compatible with non-js etc
[05:32] <wallyworld> i agree with the nice to haves
[05:33] <wallyworld> lifeless: while i have you - i wanted to put the deleteBugTask() on IBugTaskSet. it makes sense to me that the xyzSet interfaces be used to manage the lifecycle of the items they create etc
[05:33] <wgrant> Any method on a Set that isn't set-based is a bug.
[05:33] <wgrant> deleteBugTasks(), perhaps.
[05:33] <lifeless> opinions are mixed about the *Set interfaces/instances
[05:34] <lifeless> they are misnamed for much of what they do
[05:34] <wgrant> wallyworld: Also, that doesn't work too well for the API.
[05:34] <wgrant> As the Sets can't really be exported sensibly.
[05:34] <wallyworld> agreed. that was the issue i was going to aks about
[05:34] <wgrant> This is most inconvenient.
[05:34] <lifeless> putting it on there would be fine by me; I agree that it should take an interable of tasks, as future proofing. The API side of it is interesting though, as (IIRC) we haven't exposed the Sets on the PAI
[05:34] <wallyworld> we export IBranchSet
[05:34] <wallyworld> but it needs a url and default collectio method
[05:35] <wgrant> We can't use a Set here.
[05:35] <wgrant> As we need permission checking.
[05:35] <wallyworld> we pass in the user as part of the request
[05:35] <lifeless> wgrant: that seems like a non-sequitur
[05:35] <wallyworld> deleteBugTask(bugtask, deleted_by)
[05:35] <wgrant> lifeless: Until it's not awkward as hell, it's very relevant.
[05:36] <lifeless> wgrant: its not awkward as hell ...
[05:36] <wgrant> You have to manually work out the security stuff.
[05:36] <wallyworld> and we use call_with(who_deleted=REQUEST_USER)
[05:36] <wgrant> Sure, we can get the user in there.
[05:36] <lifeless> do you mean 'you'd have to check the security by probing rather than security adapters' ?
[05:36] <wallyworld> that seems to be the pattern used everywhere else
[05:36] <wgrant> But then you have to manually determine and invoke security adapters.
[05:38] <wallyworld> i like the idea of a separate manager type interface to control the lifecycle of objects
[05:39] <wallyworld> it fits more with a service based design where domain objects encapsulate state and services manage the workflow etc
[05:39]  * StevenK attempts to stop his eyes glazing over
[05:40] <wallyworld> so we need to stick the deleteBugTask() method somewhere other than on IBugTask itself or even IBug
[05:40] <wallyworld> StevenK: you know you love this stuff
[05:40] <lifeless> wallyworld: the current pattern in LP, for good or ill, is destroySelf()
[05:40] <StevenK> Love to see it burn, sure.
[05:40] <wallyworld> yuk!
[05:40] <wgrant> wallyworld: I would introduce BugTaskSet.delete(sequence_of_tasks)
[05:40] <StevenK> IBugTask.destroySelf()
[05:40] <wgrant> Then BugTask.destroySelf calls that.
[05:40] <wallyworld> nooooooo
[05:41] <wallyworld> domain objects do not call services
[05:41] <wgrant> In our current architecture they do.
[05:41] <lifeless> wallyworld: we don't have a domain/service split today
[05:41] <wallyworld> domain objects should just encapulate state and nothing more
[05:41] <wgrant> Yes, it is bloody awful.
[05:41] <wgrant> But this is Launchpad.
[05:41] <wallyworld> lifeless: yes, but do we want to propogate bad edesign?
[05:41] <wgrant> We have no choice here.
[05:41] <lifeless> wallyworld: introducing one incrementally is fine, but I would like to have some confidence we won't get lots of stubby attempts that don't flow together
[05:42] <wallyworld> sure
[05:42] <wgrant> The current API and security design mandates that the method be on the object.
[05:42] <wallyworld> so given we have an addTask method on IBug, i could put a deleteTask method there too
[05:42] <wallyworld> and then it can update the heat etc
[05:42] <nigelb> wgrant: Did you see the new design github deployed? It reminds me of old Launchpad :P
[05:42] <lifeless> I don't think destroySelf is 'bad design' - its the logical consequence of the design of the zope stack.
[05:42] <wallyworld> just like addTask does
[05:42] <lifeless> wallyworld: -the entire stack-
[05:42] <wgrant> nigelb: Indeed, with the tabs along the top.
[05:43] <wallyworld> lifeless: destroySelf is ok, but that should not be exposed via the service layer
[05:44] <wgrant> wallyworld: What service layer?
[05:44] <StevenK> The API, I guess
[05:44] <wallyworld> wgrant: i'm generising
[05:44] <wgrant> LP has no layers.
[05:44] <lifeless> wallyworld: consider the interactions between ORM-objects-are-content-objects, security adapters and highly delegate-to-content-object design
[05:44] <lifeless> wallyworld: if you grok that, and still want to add a service layer as part of this work, you have my blessing.
[05:45] <lifeless> wallyworld: few folk do grok all those interactions though :( [because its bloody vicious]
[05:45] <wallyworld> lifeless: i'd like to move to a different design which separates out content from behaviour from workflow modelling from business process modeliing from orm etc
[05:45] <wallyworld> but that's in an idea lworld
[05:46] <wallyworld> i realise we have something different
[05:46] <wallyworld> largely dictated by the design of the zope stack i guess
[05:46] <wallyworld> lifeless: wgrant: so you happy if i add a deleteBugTask method to IBug?
[05:47] <wallyworld> and if so,i would raise an exception if a bug task were passed in that didn;t belong to the bug?
[05:47] <wgrant> wallyworld: I don't think it should be on the bug.
[05:47] <wgrant> addTask is there because it's adding a task to the bug.
[05:47] <wallyworld> but the bug needs to be involved because it needs to update bug heat
[05:47] <StevenK> I think it should be on the task
[05:47] <wgrant> Fucking bug heat.
[05:48] <wgrant> Kill it.
[05:48] <wallyworld> so if it is on the bug task, i would need to update bugg heat still
[05:48] <wallyworld> and call back to the parent bug
[05:48] <wallyworld> sigh
[05:48] <wgrant> Well, ideally the *Set method would do that.
[05:48] <wgrant> In a batch fashion.
[05:49] <wallyworld> yes, but to expose the IBugSet method - it needs a url and a default collection method
[05:49] <wallyworld> and there isn;t one at the moment
[05:49] <wgrant> Sure, which is why you put a trivial method on BugTask to delegate to it.
[05:49] <wgrant> Matching the rest of LP's deletable objects.
[05:49] <wallyworld> ok, but i will have to have a shower afterwards. that is just sooooo wrong
[05:49] <poolie> i was thinking the other day about bug 678090 - i'd like to see how many people are actually affected by bugs, across dupes
[05:50] <_mup_> Bug #678090: Affected people from duplicates aren't included in the master bug's affected count <affectsmetoo> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/678090 >
[05:50] <poolie> stub, or someone, could you comment on my db performance question on the bug
[05:50] <poolie> basically, is counting them at run time going to be fast enough, or should we maintain a count?
[05:50] <wallyworld> wgrant: StevenK: to do it on bugtask seems the best option, but it just gets the layering *completely* wrong :-(
[05:50] <wgrant> wallyworld: It's as good as it can get now.
[05:51] <wgrant> wallyworld: Until we end up with a sensible architecture.
[05:51] <StevenK> "lol"
[05:51] <wgrant> Which may happen in 10 years when we're out of criticals :)
[05:51] <wallyworld> yeah :-(
[05:51] <wgrant> But don't worry, there's nothing wrong :)
[05:52] <wallyworld> wgrant: i have to run away and pick up the kid from school. i doubt we'll see any qastaging email today :-(
[05:52] <nigelb> How do I find which things are exposed over the API and wwhich arent?
[05:52] <poolie> nigelb: search through http://launchpad.net/+apidoc ?
[05:53] <wallyworld> nigelb: they are annotated and also listed in the webservice.py modules
[05:53] <nigelb> poolie: Well, I was asking from the point of looking at the code and figuring out
[05:53] <wallyworld> that's if you want to see in the code
[05:53]  * wallyworld runs away
[05:53] <nigelb> aha
[05:53] <StevenK> nigelb: They are declared in the relevant interfaces
[05:54] <nigelb> Ah, anything declared in the interface is available over the API?
[05:54] <StevenK> No, it needs to decorated
[05:55] <StevenK> nigelb: Taking lib/lp/bugs/interfaces/bug.py, getVisibleLinkedBranches is exported since it is has a @export_read_operation() decorator
[05:55] <lifeless> 18:50 < lifeless> wallyworld: I want what you want, I just see more things in the way :)
[05:55] <nigelb> funnily enough, I was looking at that exact file.
[05:55] <lifeless> and
[05:56] <lifeless> 18:49 < wgrant> Matching the rest of LP's deletable objects.
[05:56] <StevenK> nigelb: latest_patch_uploaded is exported, but latest_patch is not
[05:56] <lifeless> before my connection crapped out.
[05:56] <lifeless> I see an ISP change in my future
[05:56] <StevenK> Haha
[05:56] <StevenK> I suggest a country change first
[05:56] <lifeless> StevenK: layer 2 blip
[05:56] <nigelb> Or a continent
[05:56] <lifeless> nigelb: I've the choice of two right now, just need to drive over the mountains :)
[05:57] <nigelb> heh
[05:58] <StevenK> Haha
[05:58] <StevenK> nigelb: Clear as mud?
[05:58] <nigelb> StevenK: clearer than before at least
[05:58] <StevenK> Haha
[05:59] <StevenK> nigelb: So exporting things that haven't been can be easy if the interface they are in has had some groundwork laid -- but it can be complicated too
[06:00] <nigelb> StevenK: Ok, so the reason I asked is searchTasks is available over the API, but I don't see BugTaskSearchParams anywhere
[06:00] <stub> poolie: There will be little difference between filtering duplicates like we currently do and counting them. It may well be much faster even, as we may be able to avoid joining the bug table in some cases.
[06:01] <lifeless> stub: bug.private
[06:01] <stub> lifeless: Which is starting to be overhauled in any case.
[06:02] <lifeless> stub: yes, but we still need to know, don't we ?
[06:02] <stub> lifeless: It will move to task I think, as your bug could be targetted at pillars with different policies? Anyway...
[06:02] <poolie> so at the moment it does
[06:03] <poolie> select affected_user_count from bug where bug.id = %d
[06:03] <wgrant> stub: We're actually very strongly leaning to removing cross-pillar private bugs.
[06:03] <poolie> we could change that to
[06:03] <wgrant> stub: Once we beat OEM and ISD into submission.
[06:04] <wgrant> Hm.
[06:04] <stub> poolie: The query for 'users affected by this bug' will be slower and more complex if you count duplicates, but it will still be fast.
[06:04] <poolie> select count(user) from bugaffectsuser where bugaffectsuser.bug = %d or bugaffectsuser.bug in (select id from bug where duplicateof = %d)
[06:04] <wgrant> We need a rabbitmq logging transport.
[06:04] <poolie> or something like that
[06:05] <poolie> that's more or less what bug.affected_user_count_with_dupes does
[06:05] <stub> wgrant: I thought of that but was worried about clogging rabbit with debug2 spam.
[06:05] <wgrant> stub: Yeah, it would need testing.
[06:05] <lifeless> wgrant: this is for realtime logging?
[06:05] <wgrant> lifeless: Yes.
[06:06] <lifeless> wgrant: the ISP project should cover that
[06:06] <lifeless> wgrant: I'd rather not overlap for a bit at leasrt
[06:06] <wgrant> Yes, but they're nearly as slow at feature development as we are.
[06:06] <nigelb> ISP?
[06:06] <stub> wgrant: Would involve hooking into the existing log_options crud, adding an option to control the level of messages to send to messaging, and a log handler installed that sends to rabbit. Not terribly much work once rabbit is operational.
[06:06] <lifeless> nigelb: information systems projects
[06:06] <wgrant> stub: Yep, fits in very well with the existing script logging infrastructure.
[06:07] <nigelb> lifeless: ah
[06:07] <lifeless> StevenK: you wanted a review?
[06:07] <lifeless> speaking of which, I could use a couple
[06:07] <StevenK> lifeless: You're like an hour late.
[06:08] <lifeless> StevenK: so you don't ?
[06:08] <lifeless> oops-tools test time down to 4.7 seconds + db setup of maybe 7
[06:08] <lifeless> \i/
[06:08] <StevenK> lifeless: No, wallyworld has done it for me, but thanks
[06:13] <poolie> stub: so you're still pretty sure that will be safe?
[06:14] <lifeless> poolie: we bring up the dupes already
[06:14] <stub> poolie: Yer.
[06:14] <lifeless> poolie: I suggest not changing that query
[06:14] <lifeless> poolie: instead, sum up the affecting counts from the dupes (that we already retrieve)
[06:14] <poolie> ok
[06:15] <poolie> good idea
[06:15] <poolie> that's not precisely accurate in the case one person is affected by multiple bugs
[06:15] <poolie> but, perhaps that's not important
[06:15] <lifeless> I think for dupes that it doesn't matter :)
[06:16] <poolie> tags +pedantic
[06:16] <poolie> ok that seems pretty safe then
[06:16] <poolie> how about for sorting by affected-users across dupes?
[06:17] <lifeless> what do you mean ?
[06:18] <poolie> part of the related bug is that getting a list of bugs sorted by number of affected users probably should sort by total affected users across bugs
[06:18] <lifeless> ah
[06:18] <poolie> if you want to know which bugs cause the most pain
[06:18] <lifeless> perhaps we should stop offering that sort
[06:18] <poolie> !
[06:18] <lifeless> because bug heat is intended to provide a unified value representing pain, interest etc
[06:19] <poolie> but it fades over time, right?
[06:19] <poolie> though apparently not really?
[06:19] <lifeless> right
[06:20] <lifeless> and for affected users, wouldn't something that 1000 people marked affecting me in 2005 be less interesting than one where they marked it that way yesterday?
[06:20] <poolie> i don't know what the fall off is
[06:20] <lifeless> [Note: I'm not endorsing that decay is useful, just taking it as an axiom for the discussion]
[06:20] <poolie> it seems reasonable to want to know about either of them
[06:21] <lifeless> poolie: IIRC 1% a day or something
[06:21] <lifeless> poolie: everything in the UI has a cost; I'm questioning the value of the affected-user-sort
[06:21] <poolie> so
[06:21] <lifeless> given we have something intended to be more than it
[06:21] <poolie> i think it's a good question
[06:22] <poolie> i guess i dislike that both heat and affectance have this "you don't need to know that" attitude
[06:22] <poolie> and heat has some bugs, due to eg security bugs (many marked in error) getting a big boost
[06:22] <poolie> but, perhaps they can just be fixed
[06:23] <poolie> and it'll be a reasonable default
[06:23] <lifeless> rhetorical question: if you fix both affected and heat to be perfect, would we need both anymore ?
[06:23] <lifeless> [modulo the 'stop bug noise' aspect of affected]
[06:23] <lifeless> affected users count towards heat
[06:23] <poolie> another good question
[06:23] <poolie> i know
[06:24] <poolie> i think they mesh without overlapping much
[06:24] <poolie> if bug heat worked well i don't think i'd care much about sorting by #affected
[06:24] <lifeless> anyhow, I bet that a self join onto duplicates will trigger table scans in Ubuntu bug searches unpleasantly often.
[06:24] <poolie> but i do want to know the number of affected people
[06:24] <lifeless> thats a WAG, needs testing to be sure.
[06:24] <lifeless> poolie: I totally support showing the # affected sanely ;)
[06:25] <poolie> conversely, i think the heat metrics on an arbitrary scale have little or no value, cause confusion, and ought to be removed or deemphasized - ie make it only an ordering
[06:25] <poolie> eg the (fairly hot :) bug about heat being per-bug vs per task
[06:27] <poolie> what do you think?
[06:27] <lifeless> I think heat is an ambitious project that we've underdelivered on
[06:27] <lifeless> it has many significant operational issues as well as the UI related ones you refer to
[06:28] <lifeless> folk like deryck are keen to fix it, but the current approach is tweaking;
[06:28] <lifeless> I think it needs ground up re-evaluation, to fix both the UI and operation issues
[06:28] <lifeless> (e.g. it causes search timeouts)
[06:30] <poolie> well, i am kinda tweaking here
[06:30] <poolie> a rethink could be good
[06:32] <poolie> but, perhaps is not necessary to just make dupes work better
[06:32] <lifeless> sure; we were talking about the affected sort, which is a bit orthogonal to dupes
[06:33] <poolie> s//affectsmetoo
[06:33] <poolie> i mistyped
[06:33] <poolie> mis-thought
[07:13] <rvba> Hi lifeless, thanks for your feedback on the weird storm behaviour, I was a little bit surprised to see such a crazy thing but you're right, it really seems like I should fix this in storm (as opposed to a quick fix in the batchnavigator).
[07:34] <lifeless> rvba: you may want to fix batchnav too, as google won't be making up those urls itself - we're emitting them somewhere
[07:35] <lifeless> rvba: you can use googles link: search to find the pages containing the bad url and look at whats happening there
[07:35] <wgrant> Why won't it be?
[07:35] <rvba> lifeless: not sure about that, I've heard that google tried to fiddle with query parameters to crawl the web.
[07:35] <lifeless> wgrant: because its a spider, not an AI
[07:35] <wgrant> lifeless: Erm...
[07:35] <lifeless> rvba: ah.. well, its worth checking that we're not emitting them
[07:35] <lifeless> rvba: on the 'better safe than sorry' side
[07:35] <rvba> lifeless: Right.
[07:37] <lifeless> grah. ISP DIE DIE DIE DIE
[07:38] <lifeless> ....
[07:38] <lifeless> .
[07:38] <lifeless> .
[07:38] <lifeless> I wonder if setting my MSL to 5 seconds would help things or wreck em
[07:55] <mrevell> Howdy
[07:55] <rvba> Hello mrevell!
[07:59] <mrevell> hallo rvba
[08:06] <allenap> stub: Thanks for the review. I don't mind the crapping-on :) I wasn't sure of the fix, but I wanted to show you something that might illustrate the problem. I'm going to relocate now, back in ~20m.
[08:17] <stub> allenap: So the fix should be pretty simple - just need to add to is_disconnection_error() in databases/postgres.py. Tests might be harder to engineer, although for all I know perhaps the existing test suite fails under Oneiric.
[08:17] <stub> allenap: Assuming you want to work on it rather than hand ball it a Storm dev (me or jamesh would be most likely to grab this one)
[08:34] <poolie> o/ mrevell
[08:35] <mrevell> hey poolie, not so loud, I'm hiding from the 50ft marshmallows.
[08:35] <lifeless> I need a guinea pig
[08:35] <mrevell> s/ft/tonne
[08:36] <poolie> :) who _are_ you going to call, mrevell? :)
[08:36] <lifeless> how wide must a ft long marshmallow be to weight a tonne ?
[08:36] <mrevell> Heh. Hmm, who's the most Dan Ackroydy member of the team.
[08:36] <poolie> Huw?
[08:37] <lifeless> you gonna call...
[08:37] <lifeless> that was terrible poolie
[08:37] <mrevell> hah
[08:37] <poolie> :)
[08:37] <poolie> actually he does also look vaguely like him
[08:38]  * lifeless puts out the call for guinea pigs
[08:39] <mrevell> lifeless, Id the experience you have planned for these guinea pigs too scary to describe in your sales pitch?
[08:39] <mrevell> Feck, "Is"
[08:40] <lifeless> yes, of course
[08:40] <lifeless> :)
[08:40] <lifeless> mrevell: I want someone to quickly once-over the oops-tools release branch I've prepared
[08:41] <lifeless> mrevell: its mind numbing looking for any production data references I've missed *that matter*
[08:41]  * bigjools wonders who Robert Collings is
[08:42] <lifeless> probably the dude whose mail I keep getting
[08:42] <lifeless> from hotels, gyms, their daughters wow account [parental control bit woo] and more
[08:42] <lifeless> the sheer number of services that *don't* do a probe to check they got the mail address right is astonishing
[08:43] <bigjools> lifeless: well he attended the TL call last night
[08:43] <lifeless> bigjools: ah, no idea then.
[08:43] <lifeless> anyhow
[08:44] <lifeless> someone, please pull bzr+ssh://devpad.canonical.com/code/robertc/python-oops-tools and check I didn't miss anything big
[08:44] <lifeless> kthanks release
[08:47] <wgrant> That's very FHS.
[08:48] <nigelb> FHS?
[08:48] <wgrant> Filesystem Hierarchy Standard
[08:48] <nigelb> Hrm, maybe I don't wanna know.
[08:49] <nigelb> Ok, urbrandictionary'ing it wasn't a great idea.
[08:53] <StevenK> FHS mandates things like binaries in /bin or /usr/bin, things that the machine serves go under /srv, /usr/local is for locally installed stuff, etc, etc
[08:53] <nigelb> Ah
[08:55] <lifeless> wgrant: you didn't know about /code ?
[08:56] <lifeless> so that was amazing time consuming; I think for qatagger I'll rewrite
[08:56] <wgrant> lifeless: I didn't.
[08:57] <StevenK> The FHS didn't specify /code last I read it.
[08:58] <lifeless> it doesn't
[08:58] <poolie> what do you want people to look for?
[08:58] <lifeless> poolie: stuff we wouldn't be happy pasting in this channel
[08:59] <lifeless> machine name references, internal config details, that sort of thing
[08:59] <poolie> grep -ir f.ck .
[08:59] <nigelb> heh
[09:00] <lifeless> there are some I've deliberately kept, because we depend on them for some of the aggregation (but those are obvious when reading the code) - and already known via lp source I strongly suspect :)
[09:00] <poolie> lifeless: well, the buildout.cfg has canonical.com as example data
[09:00] <poolie> if anyone else runs this we might be annoyed by backscatter
[09:00] <poolie> or they might be embarrassed by it
[09:00] <lifeless> poolie: thanks - thats one I missed, and exactly what I was hoping for
[09:00] <lifeless> this has been brain numbing :)
[09:01] <poolie> thanks :)
[09:01] <poolie> there is no obvious licence on it
[09:02] <poolie> and the readme's "for more information" is a private url
[09:02] <poolie> also the "real world example" url
[09:03] <lifeless> no licence? where are you looking
[09:03] <lifeless> ah, I haven't overhauled README.
[09:03] <lifeless> shall do.
[09:03] <poolie> oh, the top-level readme
[09:03] <poolie> there is one in the python module
[09:04] <poolie> some of it is agpl and some is lgpl?
[09:04] <lifeless> should be all AGPL
[09:04] <poolie> (which can be valid, but may not be intentional)
[09:04] <lifeless> presumably I missed a header
[09:05] <poolie> src/oopstool/README.txt
[09:05] <lifeless> thanks
[09:05] <poolie> oh no
[09:05] <poolie> it has doctests
[09:05] <poolie> better fix that ;)
[09:06] <lifeless> its a child of its time
[09:06] <lifeless> I have purged many
[09:07] <lifeless> however my goal is a release not code overhaul
[09:07] <lifeless> I suspect folk interested will poke at it after its out there
[09:08] <poolie> i know, i was just joking
[09:09] <poolie> in models.py there is some code flagged as lp-specific
[09:10] <poolie> embedding some policy about lp custom exceptions
[09:10] <poolie> probably fairly harmless to leave it as an example in the first relase thoug
[09:11] <poolie> that's all i can find
[09:11] <poolie> that's great to get this released!
[09:12] <nigelb> what does this do?
[09:12] <nigelb> oops tools?
[09:12] <lifeless> poolie: yeah, thats the code I was referring to that needs to stay
[09:12] <lifeless> poolie: theres no extension points for this yet
[09:13] <lifeless> poolie: we need to make these data driven or something
[09:13] <poolie> nigelb: you may never have seen this but occasionally launchpad times out
[09:13] <poolie> :P
[09:13] <poolie> those things are gathered into a database and there's a tool that does some summaries and reporting
[09:13] <poolie> which we're apparently now going to release \o/
[09:13] <nigelb> poolie: heh, I did guess right :)
[09:24] <allenap> stub: Storm does string matching in is_disconnection_error. Do you think I should stick with that, or should I use pgcode like in my Launchpad branch?
[09:26] <stub> allenap: It does string matching because we were not getting error codes before for these exceptions. I think error code matching is better as we don't need to worry about localization issues. Perhaps we can do this for the other disconnections too under Oneiric and leave the string matching for backwards compatibility with older psycopg2/libpq releases?
[09:26] <poolie> jtv, fair enough
[09:26] <jtv> poolie: "just following orders"  :)
[09:28] <allenap> stub: Okay, I'll try to use pgcode if it exists, and I'll leave the fallback to string matching in place too. Thanks.
[09:34] <jtv> Anyone here who can help with a failing code import?  https://answers.launchpad.net/launchpad/+question/174071
[09:41] <bigjools> jtv: jelmer is the best to ask about that
[09:42] <jtv> Thanks bigjools
[09:47] <poolie> can anyone explain this test failure? https://pastebin.canonical.com/54298/
[09:48] <wgrant> allenap: ^^
[09:48] <wgrant> poolie's issue looks like yours.
[09:50] <poolie> i do have some lines like this in the postgres log
[09:50] <poolie> [2011-10-13 20:45:26 EST] mbp@launchpad_ftest_template_17866 FATAL:  database "launchpad_ftest_template_17866" does not exist
[09:53] <jtv> jelmer_, is this something you can help with?  https://answers.launchpad.net/launchpad/+question/174071
[09:53] <jtv> poolie: I get those log lines too
[09:53]  * allenap looks
[09:53] <jtv> Yup, that's the one allenap's working on.
[09:53] <bigjools> poolie: oneiric>
[09:53] <bigjools> ?
[09:54] <allenap> poolie: bug 871596
[09:54] <_mup_> Bug #871596: Not handling administrative shutdown under Oneiric <build-infrastructure> <librarian> <Launchpad itself:Invalid by allenap> <Storm:In Progress by allenap> < https://launchpad.net/bugs/871596 >
[09:54] <bigjools> allenap: you might want to announce you're fixing that on the dev list, we'll get loads of questions about it today
[09:54] <poolie> hooray for chroots
[09:58] <lifeless> poolie: no other feedback ?
[09:58] <lifeless> poolie: e.g. 'you need a copy of the GPL in there :P' (one I just noticed)
[09:59] <sladen> mbp pointed me this way.  What's the up-to-date method for getting a LP install working, such that I can test a proposed patch to Malone
[09:59] <nigelb> sladen: are you on oneric?
[10:00] <poolie> lifeless: that's all i can find
[10:00] <poolie> o/ paul
[10:00] <nigelb> you can either sacrifice your apache to LP or you can run it in a container
[10:00] <poolie> dev.launchpad.net/Running
[10:00] <wgrant> /Running/LXC if you want more isolation
[10:00] <sladen> https://dev.launchpad.net/Getting <-- there's that, is it current?
[10:00] <nigelb> https://dev.launchpad.net/Running/LXC
[10:01] <poolie> those two
[10:01] <wgrant> Right, that works too, if you want to sacrifice your system postgres and apache to LP.
[10:01] <poolie> personally i use Schroots
[10:01] <nigelb> sladen: it is current, but like I said. Sacrifice involved :)
[10:02] <lifeless> Running/LXC is my recommendation
[10:06] <danilos> jtv, thanks for taking care of that en_GB removal request
[10:06] <lifeless> ok, bzr+ssh://devpad.canonical.com/code/robertc/python-oops-tools should be in shape now
[10:06] <lifeless> poolie: care to eyeball again ?
[10:06] <jtv> danilos: np.  Just realized though that we'll need to delete the POFile as well.  :(
[10:08] <poolie> lifeless: sorry i have to go out, maybe tomorrow
[10:08] <poolie> well, maybe just the diff, ok
[10:08] <lifeless> its a push--overwrite, but you can use heads and diff the two
[10:08] <poolie> someone read https://code.launchpad.net/~mbp/launchpad/612171-diff-generation-spam/+merge/79244 for me?
[10:10] <lifeless> no diff yet, but I've added commentary based on your cover letter
[10:10] <lifeless> I'm v tired so lets talk about it tomorrow
[10:10] <poolie> thanks
[10:10] <poolie> how ironic if the diff fails
[10:11] <poolie> np
[10:13] <poolie> lifeless: looks pretty good
[10:13] <poolie> not sure if you ticked off every item i mentioned (that you want to fix)
[10:18] <poolie> ok night all
[10:19] <nigelb> night poolie
[10:24] <lifeless> poolie: I updated both README's, added LICENSE, and fixed buildout.cfg, deleted the isd and u1 index templates and made the LP one be called index (its a bit ugly that thats in-tree, but ... meh)
[10:27] <lifeless> and bleh png files to nuke too
[10:27] <lifeless> done
[10:29] <lifeless> wgrant: care to add some paranoia to this process?
[10:31] <wgrant> lifeless: Is the devpad branch up to date?
[10:31] <wgrant> Looks like it.
[10:31] <wgrant> As I must pull --overwrite
[10:33] <wgrant> lifeless: Don't want to s/lp-oops.canonical.dev/oops-tools.dev/ or so?
[10:34] <lifeless> sure, can do that
[10:35] <wgrant> The remaining sample OOPSes are non-sensitive?
[10:35]  * wgrant checks.
[10:36] <wgrant> Ah, you must have mangled them.
[10:40] <lifeless> hatchet and slashet
[10:40] <lifeless> pushed that sed up
[10:41] <wgrant> Getting distribution for 'wadllib'.
[10:41] <wgrant> error: Couldn't find a setup script in /usr/lib/python2.7/dist-packages
[10:41] <wgrant> An error occured when trying to install wadllib 1.2.0.Look above this message for any errors thatwere output by easy_install.
[10:41] <wgrant> :(
[10:42] <lifeless> details :P - bootstraps on lucid with the lazr sourcedeps branch
[10:42] <wgrant> (oneiric)
[10:42] <wgrant> I just ran make
[10:42] <wgrant> Which grabs that branch.
[10:42] <lifeless> (yay)
[10:42] <lifeless> so, I think once we get this out, someone probably wants to run around and cleanup
[10:43] <lifeless> I mean I don't want it to be terrible
[10:43] <wgrant> Perhaps the system wadllib is killing it.
[10:43] <lifeless> but diminishing returns and all
[10:43] <wgrant> Anyway, will ignore for now.
[10:45] <wgrant>     maintainer_email='launchpad-developers@lists.launchpad.net',
[10:45] <wgrant> Really?
[10:45] <wgrant>     license='LGPL v3',
[10:45] <wgrant> Lies.
[10:46] <lifeless> bah
[10:46] <lifeless> the former - etired. the second, grrr
[10:46] <lifeless> trove classifiers are where its at
[10:46] <wgrant> Yep.
[10:47] <lifeless> deleted the license line and fixed the list
[10:47] <wgrant> Thanks.
[10:47] <wgrant> Checked that the secret key doesn't match prod?
[10:48] <lifeless> secret key ?
[10:48]  * sladen deletes some Top Gear to make way for Launchpad.  I hope you're all grateful
[10:48] <wgrant> In buildout-templates/src/oopstools/settings.py.in
[10:49] <allenap> stub: I'm struggling to replicate the admin_shutdown thing in a Storm test. Do you know how I can do that?
[10:50] <lifeless> changed to 12345
[10:50] <lifeless> and added a note to the README
[10:50] <wgrant> Thanks.
[10:50] <lifeless> thank &you&
[10:51] <lifeless> allenap: python-pgbouncer perhaps ?
[10:52] <wgrant> lifeless: So, I think that looks fine otherwise!
[10:54] <allenap> lifeless: Ah, okay, that's already in LP, right?
[10:55] <lifeless> allenap: as a dep? yes
[10:55] <lifeless> allenap: its how we do the fdt tests
[10:56] <wgrant> lifeless: Huh, do the tests pass now?
[10:56] <wgrant> I see matsubara's email address in report.txt, but nowhere else in the codebase.
[10:57] <lifeless> they were before the latest set of edits
[10:57] <lifeless> fixing
[11:08] <lifeless>  Ran 23 tests in 4.600s
[11:08] <lifeless> OK
[11:08] <wgrant> Excellent.
[11:09] <wgrant> That's nice and quick, too.
[11:09] <wgrant> Can you do the same thing to LP? :)
[11:09] <lifeless> if I can delete the same amount, sure
[11:10] <danilos> jelmer_, hi, do you think you could QA bug 485932 or share some instructions on how to do it?
[11:10] <_mup_> Bug #485932: should stack foreign branch imports <code-import> <lp-code> <qa-needstesting> <Launchpad itself:Fix Committed by jelmer> < https://launchpad.net/bugs/485932 >
[11:11] <stub> allenap: One approach that might work is to open a second connection and 'select pg_terminate_backend(procpid) from pg_stat_activity where datname='$testdbname' and procpid <> pg_backend_pid()'
[11:13] <stub> allenap: That might work. There is a chance it is a pgbouncer specific thing and we would need to pull in the python-pgbouncer as lifeless suggested.
[11:21] <allenap> stub: I'll give that a go, thanks :)
[12:27]  * sladen gets to  utilities/update-sourcecode
[12:28] <sladen> what does  "bzrlib.errors.ConnectionReset: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist."  mean?
[12:29] <sladen> http://pastebin.ubuntu.com/707303/
[13:04] <deryck> Morning, everyone.
[13:05] <nigelb> Morning deryck. The mockups for the buglists look cool! Can't wait to see it in action :)
[13:05] <deryck> nigelb, cool.  Glad you like it.
[13:05] <StevenK> Neither.
[13:05] <StevenK> Are they implemented now?
[13:05] <StevenK> How about now?
[13:51] <rvba> Morning jcsackett.
[13:51] <jcsackett> morning, rvba.
[13:54]  * jcsackett decides he needs more coffee after looking at the review queue
[13:54] <rvba> hehe
[14:03] <rvba> jcsackett: I'm sorry but I'm stuck with a critical bug I need to work on ... I'll take new reviews; I know the review queue is a little bit daunting.
[14:05] <jcsackett> no worries, rvba. i'm juggling things today as well -- it happens. :-)
[14:06] <rvba> jcsackett: ;)
[15:01] <deryck> abentley, mumble time?
[15:41] <nigelb> sinzui: Hey, you have a few minutes?
[15:42] <sinzui> I will in a few minutes :)
[15:44] <nigelb> :)
[16:05] <mrevell> Hey deryck, do you have time to talk about Steve Magoun's email in the next hour or so?
[16:06] <deryck> mrevell, yeah, I can chat now.
[16:06] <deryck> mrevell, mumble?
[16:06] <mrevell> sounds good
[16:06] <deryck> mrevell, meet me in Orange 1 o 1 then.
[16:07] <mrevell> It's refusing to let me join
[16:25] <sinzui> nigelb, I can talk now
[16:25] <nigelb> sinzui: aha, so that bug about description - the database change has landed
[16:26] <sinzui> nigelb, the status description we dropped?
[16:26]  * sinzui tries to remember
[16:26] <nigelb> no
[16:26] <nigelb> hang on
[16:27] <nigelb> the description we created in person
[16:27] <nigelb> bug 5283
[16:27] <_mup_> Bug #5283: "Home page" vs. "Description" is misleading <easy> <lp-registry> <qa-needstesting> <tech-debt> <ui> <Launchpad itself:Fix Committed by nigelbabu> < https://launchpad.net/bugs/5283 >
[16:27] <sinzui> ah description and home_page
[16:28] <nigelb> So, now its land garbo job and the temporarily insert into both columns.
[16:28] <nigelb> I'm stuck at garbo job :)
[16:29]  * sinzui thinks
[16:30] <sinzui> nigelb, I wonder is step 3 (Update the index pages and forms to use the new field (do not show the old fields if the description is not empty)). is better to do next
[16:31] <nigelb> sinzui: Ah! That's slightly more easier, and makes sense.
[16:31] <nigelb> I won't be writing temporary code at least :)
[16:31] <nigelb> Ohwait.
[16:31] <nigelb> what about existing content?
[16:32] <sinzui> If we update the template to use description OR old fields, we know users are always seeing the right data
[16:33] <sinzui> the edit forms should only show the new field.
[16:33] <nigelb> Ah.
[16:33] <nigelb> That sounds good.
[16:33] <nigelb> I'll get to it :)
[16:35] <sinzui> nigelb, LaunchapdFormView has a property (default_values?) that is used to populate the form values. We often do not need it, but in this case, we can use it to concatenate the values in the old field in the rare case where an old team/person is edited
[16:35] <nigelb> okay :)
[16:38] <sinzui> nigelb, initial_values is the property that returns a dict of fieldnames and values
[16:38] <nigelb> ok!
[17:00] <mrevell> Night all
[17:49] <SpamapS> Hey guys, getting OOPS's every time I search for 'zookeeper' on https://bugs.launchpad.net/juju
[17:49] <SpamapS>  OOPS-2112K92
[17:49] <SpamapS> other searches do not timeout
[17:55] <elmo> it's a trap
[18:10] <flacoste> gary_poster: very nice changes to the YUI XHR fixtures! will make it much easier to use thanks!
[18:11] <gary_poster> cool, thanks flacoste :-)
[18:20] <lifeless> SpamapS: cool
[18:37] <deryck> lifeless, I violently disagree with "must be able to copy and paste in excel" as a requirement and that failing to do so is a regression.
[18:38] <deryck> lifeless, if that becomes a requirement we might as well never change the UI.  It's a by product of a design that you can copy in a certain order.
[18:38] <deryck> no one meant for that happen in the original design, I'm sure.
[18:45] <lifeless> deryck: they didn't, and note that I didn't keep 'copy and paste' as my proposed requirement - getting the data *into* excel is the thing they need
[18:45] <lifeless> deryck: e.g. the csv export
[18:45] <lifeless> deryck: oem /currently/ depend on this
[18:46] <lifeless> deryck: are you proposing we leave them high and dry for an unknown time period ?
[18:46] <deryck> lifeless, no, of course not.
[18:47] <deryck> lifeless, And I don't think anyone was saying that.  in fact, I told mrevell I think we can deliver csv pretty easy when we finish the bulk of the work in 4 weeks, but I'd prefer to see where we're at then.
[18:47] <lifeless> deryck: I'm saying that if they cannot meet their use case that they can currently, its a regression
[18:47] <deryck> lifeless, I thought mrevell echoed my "let's wait and see where we're at soon" sentiment.
[18:47] <lifeless> deryck: sure; I'm saying that we shouldn't open the flag to OEM until we have CSV
[18:47] <deryck> fair enough.
[18:48] <deryck> lifeless, however, I don't like the word "regression" for this.
[18:48] <lifeless> deryck: I'm not trying to say when-or-how, I'm trying to say that releasing this to them without a replacement for their use case will negatively impact them, and that we, in that discuss, were apparently not hearing that clearly enough
[18:48] <deryck> lifeless, well, to be fair, there's a lot in the email thread. ;)
[18:48] <lifeless> deryck: which is true, and fine :)
[18:49] <deryck> lifeless, and also to be fair, the fact that they get by today is a happy accident.  I certainly don't want to make things worse than now, so we're in agreement.
[18:49] <deryck> lifeless, but I just don't like all this regression talk when we never supported this use case yet.
[18:49] <lifeless> the reality is that we do support it, even though we never intended to
[18:50] <deryck> No, we don't support it.  We allow it.  Those are different things.
[18:50] <flacoste> deryck: csv export wouldn't hard, but not trivial either since we are likely to hand the CSV generation to a job as not to timeout when there are lots of bugs (we shouldn't paginate CSV exports)
[18:50] <flacoste> deryck: so we have all the infrastructure to implement this, but it's not a simple take the JSON and write it throug csv.DictWriter either
[18:51] <flacoste> well, it's that, but needs some wrapping :-)
[18:51] <deryck> flacoste, right, I didn't mean to imply it was that simple. :)  Just more attainable at the end of this work than at the beginning.
[18:51] <flacoste> deryck: agreed
[18:52] <lifeless> and I agree with the difficulty etc; I'm not suggesting we need to change the order we do the work in; but we do need to acknowledge and deal with their needs
[18:54] <flacoste> SpamapS: that looks like bug 735966, weird though that only zookeeper search triggers it
[18:54] <_mup_> Bug #735966: Product:+bugs timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/735966 >
[18:55] <flacoste> lifeless: anything that could explain that Product:+bugs time outs when trying to ftq(zookeeper), but not without it?
[18:55] <flacoste> on juju
[18:55] <lifeless> posibbly cold pages in the text index
[18:56] <lifeless> or pathological layout - we're at 98% bloat as of last night
[18:56] <lifeless> I don't think stub has managed to fix it yet
[18:57] <SpamapS> I can search for lots of other common things
[18:57] <SpamapS> just not zookeeper
[19:01] <lifeless> SpamapS: works for me
[19:01] <lifeless> SpamapS: a bit slow - 107 queries/external actions issued in 8.86 seconds
[19:01] <lifeless> re-running,
[19:01] <lifeless> timeout
[19:01] <lifeless> may be db server specific
[19:05] <lifeless> flacoste: the main bugtask search is whats timing out
[19:05] <lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-2112K92#longstatements
[19:07] <flacoste> yeah, i saw
[19:07] <flacoste> but since it seems to work for SpamAs when he doesn't use zookeeper as a term, i wondered if it wouldn't be only the ftq() clause that slows it down
[19:09] <lifeless> flacoste: SpamapS: http://paste.ubuntu.com/707506/
[19:11] <flacoste> lifeless: doesn't that confirm my hypothesis?
[19:11] <flacoste> Index Scan using bug_fti on bug  (cost=0.00..1830.44 rows=51 width=761) (actual time=45.069..10902.728 rows=71 loops=1)
[19:12] <lifeless> yes
[19:12] <lifeless> sorry, am juggling a few threads right now
[19:12] <lifeless> on my baby-addled brain (yesterday was first immunisation shots)
[19:13] <flacoste> lifeless: ouch, yeah shots, that throws a baby sleep-cycle off for a week!
[19:14] <SpamapS> lifeless: DTP, MMR, and the best immunity.. Diplomatic
[19:14] <lifeless> SpamapS: :)
[19:17] <lifeless> flacoste: so yes, 10 seconds to get 71 rows
[19:17] <lifeless> flacoste: sick index
[19:18] <lifeless> we need a new one and a pivot
[19:18] <lifeless> this isn't automated yet and is tricky to do live
[19:20] <abentley> deryck: http://people.canonical.com/~abentley/client-side-mustache.png
[19:21] <abentley> deryck: I'd like to chat about how to maintain a common template for server side and client side.
[19:22] <deryck> abentley, ok, may have to wait a bit.  I'm currently in 2 other conversations.  I'll try to wrap shortly and ping.
[19:22] <abentley> deryck: okay.
[20:31] <lifeless> flacoste:
[20:31] <lifeless> https://launchpad.net/python-oops-tools
[20:31] <flacoste> !
[20:31] <flacoste> finally
[20:32] <lifeless> flacoste: indeed, long road
[20:32] <flacoste> lifeless: thanks for pushing this past the finish line!
[20:32] <lifeless> flacoste: we still need to deal with the fallout: isd an u1 custom front pages were removed, branding cut back etc
[20:33] <lifeless> flacoste: but I think folk will step up now that we can't cheat ;)
[20:34] <lifeless> flacoste: and http://pypi.python.org/pypi/oops-tools
[20:34] <lifeless> flacoste: hasn't rendered right, but meh :(
[20:35] <lifeless> the hard part is ~ over
[20:36] <lifeless> flacoste: so we used a new project to prevent old branches being pushed wrongly; I'm going to deactivate the old project
[20:36] <lifeless> flacoste: It has 46 open bugs, I'm thinking to just manually retarget, no sql or anything - safer.
[20:36] <lifeless> flacoste: unless you have a different recommendation ...
[20:37] <flacoste> lifeless: nah, sounds fine
[20:38] <lifeless> (and am leaving closed bugs behind)
[20:48] <mwhudson> when i forget to land a change --no-qa, what should i do to the tags?
[20:48] <mwhudson> mark it qa-untestable?
[20:48] <lifeless> qa-untestable
[20:48] <mwhudson> cool
[21:09] <lifeless> and the old project disabled
[21:09] <lifeless> nigelb: lp:python-oops-tools
[21:09] <nigelb> lifeless: <3
[22:02] <wallyworld_> sinzui: mumble is taking all my cpu and freezing. trying to fix
[22:08] <jcsackett> sinzui: can you hear us?
[22:11] <mwhudson> wallyworld_: try deleting ~/.MumbleSocket or something like that
[22:11] <wallyworld_> mwhudson: i reboot fixed it, thanks :-)
[22:26] <sinzui> wallyworld_, bug 663923
[22:26] <_mup_> Bug #663923: Cannot view list archive of private team <mailing-lists> <ml-archive-sucks> <regression> <Launchpad itself:In Progress by mars> < https://launchpad.net/bugs/663923 >
[22:49]  * StevenK glares at lifeless.
[22:50] <lifeless> StevenK: oh?
[22:51] <StevenK> lifeless: Reassigning 52 bug pillars
[22:51] <lifeless> StevenK: faster this way
[22:52] <lifeless> wait for me to get going on the high review
[23:05] <StevenK> Uh oh, I've broken Mumble.
[23:05] <StevenK> I shaded it, which Unity took as minimising.
[23:06] <StevenK> Using the Mumble notification to bring the window back shows the toolbar. Only.
[23:09] <StevenK> Oh look, I fixed it.
[23:36] <lifeless> flacoste: I've mailed stub about bug_fti
[23:36] <lifeless> flacoste: to execute his evil workaround
[23:37] <flacoste> lifeless: thanks!