[08:46] <lifeless> so I have my test machine up and running, but boy was it more work than I expected
[09:11] <wgrant> lifeless: Around?
[09:12] <lifeless> yes
[09:12] <lifeless> 'sup?
[09:13] <lifeless> wgrant: ^
[09:13] <wgrant> lifeless: I tried to use testresources in lazr.amqp, with ResourcedTestCase. But it cleans and sets up the fixture for every test. Do I have to work in OptimisingTestSuite somehow?
[09:14] <lifeless> yes
[09:14] <lifeless> what test runner are you using ?
[09:14] <wgrant> At the moment it's zope.testrunner, but we're not tied to that.
[09:14] <wgrant> Will gladly abandon it.
[09:15] <StevenK> jtv!!!
[09:15] <wgrant> Still QA?
[09:15] <jtv> StevenK: ?
[09:15] <lifeless> wgrant: you will have to
[09:15] <wgrant> lifeless: Excellent.
[09:15] <StevenK> jtv: You have 4 or 5 branches of QA!
[09:15] <lifeless> wgrant: it messes with uites
[09:15] <wgrant> lifeless: Should I just use unittests?
[09:15] <jtv> StevenK: no I don't think so
[09:15] <wgrant> s/unittests/unittest/
[09:15] <lifeless> wgrant: subunit.run :)
[09:15] <jtv> StevenK: I had to fix an ancient +queue timeout though before I could do meaningful Q/A
[09:15] <wgrant> lifeless: Can I integrate that with buildout, or should I just use testr?
[09:16] <StevenK> jtv: Sorry, 3. r13302, r13318 and r13326
[09:16] <lifeless> wgrant: I don't know about buildout and tests
[09:16] <jtv> StevenK: I have zero branches in qa-needstesting.
[09:16] <jtv> Your view may be lagging.
[09:17] <StevenK> When did you change the bugs?
[09:17] <bigjools> pay attention gentlemen
[09:17] <jtv> StevenK: Sometime in the past 4 minutes.
[09:17]  * StevenK makes a ... sign at bigjools 
[09:19] <StevenK> lifeless: I am disabling parallel-test again.
[09:20] <LPCIBot> Project parallel-test build #83: ABORTED in 11 hr: https://lpci.wedontsleep.org/job/parallel-test/83/
[09:20] <lifeless> wgrant: chatting with jml for a quick 'how to glue it together' bootstrap may help you
[09:20] <StevenK> Because of ^
[09:20] <wgrant> lifeless: Thanks.
[09:21] <jtv> bigjools: pay attention
[09:23] <wgrant> lifeless: So we can't use test discovery?
[09:23] <lifeless> sure can
[09:23] <lifeless> need the discover egg
[09:24] <wgrant> How do we make it use OptimisingTestSuite then?
[09:24] <lifeless> and a root level load_tests hook to wrap things and reenter into discovery to gather the children
[09:24] <wgrant> k
[09:24] <wgrant> Will hopefully talk to jml.
[09:34] <danilos> jtv, hey, the approach of not having a separate expander/content box is not going to work because the spinner still ends up in the expander box
[09:36] <lifeless> matsubara: hi
[09:36] <lifeless> matsubara: I just wanted to check you saw my comment on the bug you incompleted
[09:36] <matsubara> lifeless, hello
[09:37] <lifeless> matsubara: (because you might not be subscribed ;))
[09:37] <matsubara> lifeless, I have now. thanks
[09:37] <lifeless> :)
[09:37] <matsubara> lifeless, yeah, I didn't get a mail notification :-)
[09:38] <matsubara> hmm I always thought incomplete could be used as a needs info
[09:38] <lifeless> if we turn bug expiry off, it could
[09:38] <lifeless> but bug expiry *ignores* whether a bug has had a reply
[09:38] <matsubara> right, got that. I won't do that anymore
[09:39] <lifeless> even if we turned it off, its a bit orthogonal
[09:39] <lifeless> we over-conflate things in the status field
[09:39] <matsubara> lifeless, btw, do you have an answer to the question I asked there?
[09:40] <lifeless> e.g. is-valid, is-bug-or-is-feature-request, is-ready-to-code and filer-has-been-asked-a-question
[09:40] <lifeless> matsubara: remind me  :)
[09:40] <matsubara> lifeless, Would it be sufficient to add another bullet point to the +mailinglist page (e.g. https://qastaging.launchpad.net/~oops-tools-dev/+mailinglist) saying something like: "Non-Launchpad users won't be able to post to this list. Launchpad doesn't send non-delivery receipts to non-LP users if they try to post to this mailing list."?
[09:40] <jml> lifeless: yes, that's what the BugLifecycle thing is partly aiming to address (or diagnose)
[09:40] <lifeless> jml: yes ;)
[09:41] <lifeless> matsubara: that would be a good thing to do. I don't think it will eliminate the confusion. It may reduce it.
[09:41] <lifeless> matsubara: I don't know if it would be sufficient.
[09:41] <lifeless> matsubara: its probably necessary (unless we change the behaviour, which is problematic for a whole other set of issues)
[09:43] <matsubara> lifeless, is there other place that documentation could be added?
[09:43] <lifeless> theres probably stuff on h.l.n about lists in general
[09:45] <matsubara> lifeless, right.
[09:45] <matsubara> I'll work on it today
[09:46] <lifeless> cool
[10:03] <bigjools> jtv: do you reckon we could make a query fast enough to make +localpackagediffs look for matching packages, packagesets and people associated with packages all at the same time?
[10:07] <wallyworld_> jcsackett: i've found some issues with non lazr-js build. am fixing now
[10:09] <jml> rvba: please use a bigger font :)
[10:35] <jtv> bigjools: we'll have to talk about it — I may not fully understand what it is you want
[11:28] <rvba> StevenK: qa-ok!
[11:37] <lifeless> huwshimi: hi
[11:37] <huwshimi> lifeless: Hey there
[11:37] <lifeless> so bug 697489
[11:37] <_mup_> Bug #697489: "Participation" and "Involvement" portlets order is different from "applications" links <easy> <ui> <users> <Launchpad itself:Won't Fix> < https://launchpad.net/bugs/697489 >
[11:41] <lifeless> huwshimi: how do you want to hae this discussion?
[11:41] <huwshimi> lifeless: Is here ok?
[11:41] <lifeless> its fine by me
[11:43] <lifeless> huwshimi: the getting involved portlet shows up on only one page
[11:43] <lifeless> huwshimi: I don't see how it can be such a key element
[11:44] <huwshimi> lifeless:  It appears in various forms on project pages, user profiles, bug listings, bugs, answers etc.
[11:44] <lifeless> nope
[11:44] <lifeless> project and person only AFAICT
[11:45] <lifeless> specifically the overview (root domain) view for pillars
[11:46] <lifeless> huwshimi: it may have been intended to be widely deployed, but it hasn't been
[11:47] <huwshimi> lifeless: How do you think most people file a bug?
[11:47] <lifeless> huwshimi: apport
[11:48] <lifeless> huwshimi: (statistically)
[11:48] <NCommander> StevenK: wgrant we should probably meet up tonight to talk about LP
[11:48] <lifeless> huwshimi: excluding that special case they use the 'report a bug' link which is visible on bugs.l.n/project
[11:48] <StevenK> NCommander: Tonight, ronight?
[11:48] <StevenK> s/r/t/
[11:49] <lifeless> huwshimi: log analysis can tell use if folk start from the project front page, but this involvement portlet is new
[11:49] <huwshimi> lifeless: Right, so that would seem like a pretty important part of the UI to me
[11:49] <lifeless> huwshimi: I suspect muscle memory has most folk starting with bugs.l.n/project
[11:49] <lifeless> huwshimi: thats a different portlet
[11:49] <NCommander> StevenK: well, its tonight, or tomorrow night, and I find that friday nights are less likely to get something done
[11:49] <lifeless> huwshimi: isn't it?
[11:50] <StevenK> NCommander: Tonight is the LP team dinner
[11:50] <StevenK> I'd suggest this afternoon
[11:50] <NCommander> StevenK: that works.
[11:50] <StevenK> NCommander: Pop your head into the LP breakout room and ask wgrant and bigjools
[11:50] <lifeless> huwshimi: even if it is the same one, the proposed change wouldn't alter that portlet on bugs.l.n, as its already in the same order as the applications bar
[11:51] <NCommander> StevenK: I'll be over in ~30 minutes
[11:51] <huwshimi> lifeless: The proposal is that all those portlets would be the same as the main tabs
[11:52] <huwshimi> lifeless: I don't think it is a bug that they are in a different order
[11:53] <huwshimi> (a different order to the main tabs)
[11:53] <lifeless> huwshimi: I thought the reported defect was that the order was inconsistent
[11:54] <lifeless> huwshimi: not that they needed the same content
[11:54] <huwshimi> lifeless: yes
[11:54] <huwshimi> lifeless: Are we not saying the same thing?
[11:55] <lifeless> I thought for a statement there that you thought the bug was larger than the order
[11:55] <lifeless> 'same as the main tabs'
[11:55] <lifeless> huwshimi: so I think its fine to say 'the order is different because (reason)' and wontfix it on that basis.
[11:56] <lifeless> huwshimi: closing something we agree is a defect really rubs me the wrong way; in the bug so far you have not indicated a preference for the status quo, rather indicated that change might (and we have no data only guesses) be expensive
[11:57] <huwshimi> lifeless: Well the bug merely says they should be the same for "consistency"
[11:58] <huwshimi> lifeless: There is no data to suggest that that is true either
[11:59] <lifeless> well
[11:59] <lifeless> there is some research out there, but I don't think its conclusive
[11:59] <huwshimi> lifeless: Can you point me towards it?
[11:59]  * lifeless digs
[12:00] <lifeless> Nielsen 1989b, http://en.wikipedia.org/wiki/User_interface#Consistency has some references
[12:01] <huwshimi> lifeless: Oh sorry I thought you meant something specific to this bug
[12:02] <lifeless> huwshimi: we don't have data on the cost of change; we don't have data on the cost of the inconsistency - thats true
[12:02] <lifeless> we have some models about potential costs for the inconsistency; and we can data mine logs to assess the cost of change if we want to
[12:09] <lifeless> huwshimi: so I'm not invested either way; As I read the report its a valid defect - but I wouldn't have called it high.
[12:10] <lifeless> huwshimi: my objection to closing it is based around whether its a valid defect or not; we shouldn't close bugs just because its tricky to do right now.
[12:12] <huwshimi> lifeless: I don't believe it is a valid defect because there is an inconsistency. As curtis mentions on the bug the order was chosen (however arbitrary that may have been).
[12:13] <huwshimi> lifeless: It is a consideration, sure, but not a bug
[12:13] <lifeless> huwshimi: curtis also says 'We want one order for all three portlet'
[12:13] <huwshimi> lifeless: Possibly we don
[12:13] <huwshimi> *we do
[12:14] <huwshimi> lifeless: It is not *wrong* that they are different
[12:14] <lifeless> huwshimi: being *wrong* is not a necessary condition to be in the tracker
[12:15] <huwshimi> lifeless: No, that's why we have statuses like "won't fix"
[12:15] <lifeless> huwshimi: huh? thats unrelated
[12:15] <lifeless> we have wontfix for things we don't want to do.
[12:16] <huwshimi> lifeless: Right, and I don't think we want to fix this
[12:17] <huwshimi> lifeless: At least not just for the sake of making it "consistent"
[12:18] <lifeless> thats not consistent with what curtis wrote earlier in the bug
[12:18] <lifeless> (heh, sorry about the reuse of consistent, brain-broke)
[12:20] <lifeless> I'm concerned that we're closing off something we would like to do (have them consistent) because the cost of change is higher than we're willing to pay for consistency.
[12:20] <lifeless> Thats getting trapped in a local trough
[12:20] <lifeless> a better thing to do is to say that we won't change it *solely* for this, leave the bug open, and when we have other reasons to change the portlets do this at the same time.
[12:21] <lifeless> the aspects of 'would we like this' and 'what is necessary to do it well/acceptably' are quite separatabl
[12:21] <lifeless> e
[12:23] <abentley> henninge: The RosettaApplicationView dates back to June 12 2005, and was last seriously touched by SteveA.
[12:27] <lifeless> huwshimi: this is dragging on too long
[12:27] <huwshimi> lifeless: So lets change this to something like opinion then?
[12:28] <lifeless> huwshimi: whats your objection to it being open with a caveat about when to do it?
[12:28] <lifeless> huwshimi: have I misunderstood you? do you actively want the portlets to have different orders?
[12:30] <huwshimi> lifeless: It's possible that a different order is actually better
[12:30] <lifeless> huwshimi: do we actually think that? curtis said that he wanted them to have the same order eventually
[12:31] <lifeless> huwshimi: if you think a different order *is* better, wontfix is totally fine, but as I understand it you haven't said that.
[12:31] <lifeless> huwshimi: you seem to be on the fence about that aspect, and unwilling to inflict a (possibly traumatic) change on our users for something you are ambivalent about
[12:32] <lifeless>  - which is totally reasonable
[12:33] <lifeless> however, curtis was totally clear that he wants all these things to have the same order, which agrees with the reporter, and combining these views suggests a real bug we shouldn't do without either more data about costs/benefits || some other change to alter the cost/benefit ratio by doing at the same time
[12:34] <huwshimi> lifeless: I would be happy with a bug that said "the current order of portlet links may not be the best possible order"
[12:34] <benji> mrevell: I changed 728193 to "In Progress"
[12:35] <lifeless> huwshimi: so change this one to say that :)
[12:35] <huwshimi> lifeless: But I don't think that's really a bug
[12:36] <lifeless> I'm getting really confused here
[12:37] <StevenK> jcsackett: https://bugs.launchpad.net/launchpad/+bug/365812
[12:37] <_mup_> Bug #365812: lazr-sam.css should be placed under lazr/build/assets/ along with required image files <easy> <javascript> <lp-foundations> <performance> <ui> <Launchpad itself:Triaged> <LAZR Javascript Library:Triaged> < https://launchpad.net/bugs/365812 >
[12:37] <lifeless> you're not stating that consistency is undesirable; you acknowledge that we may want them to be consistent; curtis *does* want them to be consistent, and the only reason presented not to harmonise things is the cost of change
[12:37] <mrevell> thanks benji
[12:37] <huwshimi> lifeless: That seems to be more of an opinion thing to actually being a bug
[12:38] <lifeless> huwshimi: sure, but its an opinion that the guy which brought in this portlet agrees with
[12:39] <lifeless> huwshimi: I've acknowledged your constraint over cost-of-change, but you still don't want this (valid) bug in the system for some reason.
[12:39] <lifeless> and I don't understand that
[12:40] <lifeless> if you're happy as things are, then cost of change is irrelevant,a nd closing it is appropriate
[12:43] <huwshimi> lifeless: So I also think there are bigger things here that make this issue kind of redundant, one of which I mentioned on the bug (about not having the "participation" portlet)
[12:45] <lifeless> huwshimi: if we've committed to doing something about it, closing wontfix (because we are doing X whichmakes redundant) also makes sense
[12:45] <lifeless> huwshimi: but if we haven't committed to doing that, or if doing that might not solve this thing, then they are different issues
[12:45] <huwshimi> lifeless: I don't really care how this is resolved. I don't think it's valid to say the portlet order should be the same as the nav which is why I closed as won't fix
[12:46] <lifeless> ah, so this is the meat :)
[12:46] <lifeless> huwshimi: do you know why curtis said that we *do* want one order for them all ?
[12:47] <huwshimi> lifeless: nope
[12:47] <lifeless> I suggest you talk to him, since you are both there.
[12:48] <lifeless> *if* we want one order, then this bug is squarely on the issue and we should update it to make sure we don't change this willy-nilly but coordinate it at some future time.
[12:49] <lifeless> if we don't want one order, then the argument about cost of change is irrelevant and wontfix is fine (but we should update it to be clear that its not wontfix-this-is-hard, its wontfix we don't *want* to be consistent.
[12:50] <lifeless> What I want is that the reasoning is clear, so that the reporter understands why, which helps them understand how we're building LP better (lots of our reporters report > 1 bug IME, and we want to help folk become contributors)
[12:52] <lifeless> huwshimi: I'm crashing now before midnight arrives
[12:52] <huwshimi> lifeless: Ok thanks for that
[12:52] <lifeless> huwshimi: thanks for your patience humouring me on this; I look forward to *one* of those things in the bug report in the morning :)
[12:53] <lifeless> unclear bug closing tends to set me off (because of the social impact it has)
[12:54] <lifeless> huwshimi: I realise this discussion probably seems a lot larger than you expected when you closed the bug :)
[12:55] <lifeless> anyhoo
[12:55] <lifeless> night all
[12:55] <lifeless> have a great day sprinting
[12:56] <wgrant> Night lifeless.
[12:59] <matsubara> anyone available for a quick review: https://code.launchpad.net/~matsubara/launchpad/772016-mailinglist-help/+merge/66443?
[13:45] <rvba> wgrant: http://paste.ubuntu.com/635746/
[13:48] <wgrant> rvba: We could have routing keys like lp.job.MergeProposalJob.1234, or lp.job.MergeProposalJob.1234.status_change, or lp.job.MergeProposalJob.1234.status.completed, or...
[13:50] <rvba> wgrant: that's the plan yes.
[14:26] <jcsackett> sinzui: how does one fire off all YUI tests at once? something with layer=YUI... yeah?
[14:34] <wgrant> jcsackett: --layer=YUI should do it.
[14:34] <jcsackett> thanks wgrant.
[14:57] <matsubara> jelmer, thanks for the review!
[14:57] <jelmer> matsubara: anytime :)
[15:00] <benji> StevenK: boo!
[15:00] <benji> StevenK: will you review https://code.launchpad.net/~benji/launchpad/bug-436247/+merge/66336 for me?
[15:00] <StevenK> benji: I could be convinced. Whaddya got?
[15:01]  * benji hands StevenK ten thousand units of his currency of choice.
[15:02] <StevenK> Haha
[15:03] <StevenK> benji: My only concern is you drop a tal:define of number_of_dupes
[15:03] <benji> ooh, looking
[15:03] <benji> StevenK: yep, that block didn't have anything in it (and defines are scoped to the enclosing tag (unless they have "global" on them))
[15:04] <StevenK> benji: Right, so it was utterly pointless
[15:04] <benji> absolutely
[15:05] <StevenK> benji: r=me
[15:05] <benji> cool, thanks
[15:53] <jml> poolie: Give lp:~jml/testtools/gassy-failure-660852 a try if you'd like
[16:21] <wgrant> allenap: http://paste.ubuntu.com/634326/
[16:25] <benji> StevenK: that was lazr.restfulclient, right?
[16:26] <StevenK> benji: Right
[16:26] <benji> k
[16:27] <benji> StevenK: I don't see a NEWS.txt entry.  What's a good one-line description of the change?
[16:27] <StevenK> benji: Best person to ask is poolie.
[16:28]  * benji sends telepathic waves towards poolie.
[16:28] <StevenK> Did they work? :-P
[16:28] <benji> not yet
[16:30] <benji> I think I'll just construct some NEWS entries from the bzr log, it looks like several people merged things in without updating NEWS.
[16:30] <benji> Bad people.  No cookie.
[16:32] <StevenK> benji: Haha, thank you for sorting it.
[16:34] <huwshimi> deryck: Do you want to review this branch? https://code.launchpad.net/~huwshimi/launchpad/bug-link-focus-749845/+merge/66474
[16:34] <deryck> huwshimi, sure.  5 minutes to finish another review, and I'll take a look.
[16:34] <huwshimi> deryck: np
[16:36] <deryck> wallyworld_, hey.  you really here?
[16:36] <wallyworld_> deryck: yes
[16:36] <wallyworld_> sometimes
[16:36] <deryck> wallyworld_, actually hold on, sorry.  taking my advice to jcsackett for a make clean first.
[16:36] <wallyworld_> ok
[16:40] <deryck> wallyworld_, false alarm.  works beautifully and diff reports the same files now.
[16:40] <wallyworld_> deryck: \o/
[16:40] <deryck> wallyworld_, so r=me.
[16:40] <wallyworld_> awesome, thanks
[16:41] <deryck> np
[16:41] <deryck> huwshimi, looking at your MP now.
[16:46] <deryck> huwshimi, come see me about your bug when you can.
[16:46] <deryck> or your MP rather
[16:46] <huwshimi> deryck: Sure, be there in a few
[16:46] <deryck> huwshimi, cool
[16:47] <benji> StevenK: ok, 0.12.0 is released
[16:47] <StevenK> benji: Thanks! Where can I grab it?
[16:48] <benji> StevenK: https://launchpad.net/lazr.restfulclient/+download
[16:50] <poolie> thanks jml
[17:16] <jml> poolie: you might want to try again with the latest branch. I've applied mgz's suggestions.
[17:20] <deryck> huwshimi, http://pastebin.ubuntu.com/635875/
[17:22] <huwshimi> deryck: Thanks for that
[17:22] <huwshimi> deryck: Do you want to approve the branch, or are you ok for me to do it?
[17:22] <deryck> huwshimi, no problem.  I added the pastebin to the MP when I approved it just now, too.
[17:22] <huwshimi> deryck: Ah awesome thatnks
[17:22] <deryck> np
[17:22] <huwshimi> *thanks
[17:28] <huwshimi> poolie: If you want to talk about the branch page any more I'm available now
[17:29] <allenap> rvba: lp:~allenap/launchpad/routing-key-generation
[17:38] <gmb> wgrant: http://oo00.eu
[17:41] <poolie> huwshimi, mrevell, would you two like to come and talk about bug workflow with ubuntu people? skaet etc
[17:41] <poolie> up on floor 2
[17:43] <huwshimi> poolie: sure, on way
[17:59] <jml> deryck: re "Big Bang Theory", http://life.metagnome.net/2011/05/crane-transposition.html
[17:59]  * deryck looks
[18:32] <wgrant> gmb: You appear to have failed to push your lazr.amqp changes. trunk still thinks it's 0.0.2.
[20:21] <timrc> wgrant, ping
[20:22] <timrc> or anyone, what's the proper way to branch a private tree and push it back to LP such that it retains its privacy settings?
[20:42] <dobey> timrc: if you're pushing to a project that has branches private by default, it will be private by default
[20:43] <timrc> dobey, not from my experience
[20:43] <timrc> dobey, at least, not with bzrlib
[20:44] <dobey> bzr is not a private project
[20:44] <dobey> its branches are public by default
[20:45] <timrc> dobey, no, I branched a private branch, made some changes, and pushed a new branch back using bzrlib
[20:45] <timrc> the new branch was public
[20:45] <beuno> timrc, that decision is made by launchpad, not bzr
[20:45] <beuno> so it depends on the location
[20:46] <dobey> pushed to where?
[20:46] <beuno> if you push back to the project with private branches by default, it will be private
[20:46] <dobey> timrc: so you're writing some script that uses bzrlib, and does the pushing/pulling bits?
[20:46] <timrc> dobey, yeah
[20:46] <timrc> maybe it's because the private branch is owned by a user and not a project?
[20:47] <beuno> it shouldn't matter
[20:47] <dobey> projects don't own branches
[20:47] <timrc> a team, rather
[20:47] <beuno> you need to find out if a project has private branches by default or not
[20:47] <lifeless> moin
[20:47] <dobey> could be the project does not have private branches by default
[20:51] <bryceh> While:
[20:51] <bryceh>   Installing scripts.
[20:51] <bryceh>   Getting distribution for 'lazr.amqp==0.1'.
[20:51] <bryceh> Error: Couldn't find a distribution for 'lazr.amqp==0.1'.
[20:52] <bryceh> this is from attempting a rocketfuel-branch after updating to latest devel today.  ideas?
[20:55] <lifeless> update your download cache
[20:56] <bryceh> yep, I think that did it
[20:56] <bryceh> thanks
[21:09] <timrc> I think my problem is that I pushed to +junk ?
[21:09] <timrc> are branches that get pushed to +junk made public?
[21:10] <lifeless> timrc: +junk is public
[21:10] <timrc> so this is just my general lack of understanding :)
[21:10] <lifeless> timrc: there is /no/ concept of 'is this thing private' for bzr
[21:10] <lifeless> timrc: so once you have a local branch, its just like every other branch
[21:10] <timrc> lifeless, this is just a result of my misunderstanding
[21:10] <lifeless> timrc: /projects/ in launchpad can define privacy rules
[21:14] <timrc> lifeless, okay
[21:46] <dobey> hrmm
[21:46] <dobey> why is most of the content in http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/gobject-introspection/maverick/view/head:/debian/control.in red text on red background? makes no sense to me :)
[21:49] <lifeless> looks lik a pygments fail
[22:07] <lifeless> dobey: file a bug ?
[22:12] <dobey> ok
[22:13] <dobey> against lp, or against... whatever that thing is called that is used for the code browsing?
[22:21] <beuno> dobey, loggerhead
[22:21] <lifeless> lp
[22:21] <beuno> against loggerhead
[22:21] <lifeless> we'll add tasks to loggerhead and a watch to pygments
[22:22] <lifeless> beuno: fixed-in-loggerhead isn't fixed-in-lp, so it needs both
[22:22] <beuno> true
[22:45] <StevenK> lifeless: O hai. Can I trouble you for a small review?
[22:47] <lifeless> of course
[22:48] <StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/branch-approximatedate/+merge/66480
[22:48] <lifeless> thats reviewed :)
[22:49] <StevenK> lifeless: Thanks. I didn't think it would be controversial :-)
[22:49] <StevenK> lifeless: As an aside, 'a moment ago' is from the branch I landed a few hours ago
[22:49] <lifeless> no worries
[22:50] <lifeless> yeah, I like the look of it
[22:50] <StevenK> I'm not sure if 10 seconds is the right answer, but it's only mentioned in one place ...
[22:55] <lifeless> That test could fail, but if wehave 10 second swap storms stalling the test runner, we have a real problem
[22:55] <StevenK> Right
[23:00] <lifeless> hows the week been ?
[23:01] <StevenK> Tiring
[23:01] <StevenK> And in fact, on that note, I'm going to bed. :-)
[23:21]  * jelmer waves
[23:22] <mwhudson> jelmer: hi!  fixed that bzr-svn bug yet? :)
[23:26] <jelmer> mwhudson!
[23:26] <jelmer> mwhudson: No, but making progress
[23:26] <mwhudson> cool
[23:26] <mwhudson> nice to see some work on loggerhead, too
[23:26] <jelmer> mwhudson, I did some manual imports of gcc today to unblock some people
[23:27] <jelmer> mwhudson, and I at least have an idea how to manually fix the issue by disabling tags for the moment
[23:27] <jelmer> mwhudson, the memory problem turns out to be the fact that we do one run of "svn log" per tag, and then keep the results of that in memory
[23:27] <mwhudson> ah
[23:27] <jelmer> gcc has ~700 tags
[23:27] <mwhudson> i can see how that would be a problem for gcc
[23:29] <jelmer> the fact that we hold that data in memory 700 times is accidental - we start iterators that we don't fully consume; but because we keep a handle to them, and because they consume data generated by independent threads, we use all that memory
[23:33] <mwhudson> ah
[23:33] <mwhudson> nice software abstractions defeat efficient performance
[23:33] <mwhudson> or something?
[23:34] <jelmer> yeah, though s/nice// because they defeat efficient performance :P
[23:35] <mwhudson> s/^/seemingly /
[23:35] <lifeless> how does one tell a doctest to run in a layer?
[23:36] <lifeless> a DocTestSuite specifically
[23:36] <mwhudson> lifeless: have you encountered test_system_documentation yet?
[23:37] <lifeless> probably
[23:37] <lifeless> I'll poke at that
[23:38] <mwhudson> ah, actually i guess lib/lp/$app/test/test_doc.py is the modern equivalent
[23:38] <mwhudson> (but test_system_documentation is still there too)
[23:39] <lifeless> ah
[23:39] <lifeless> suite.layer = x
[23:40] <timrc> I'm getting http://pastebin.ubuntu.com/636053/ when I create (bzr init) a new tree and then push it to an existing project... any idea how I can rectify this?  Appears to be some sort of compatibility issue...
[23:42] <lifeless> #bzr might be a better place to ask :)
[23:43] <timrc> lifeless, good point :)
[23:43] <timrc> my brain has married the two projects together :/
[23:45] <jelmer> they're not married, but at least very good friends :)