=== almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [08:46] so I have my test machine up and running, but boy was it more work than I expected [09:11] lifeless: Around? [09:12] yes [09:12] 'sup? [09:13] wgrant: ^ [09:13] 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] yes [09:14] what test runner are you using ? [09:14] At the moment it's zope.testrunner, but we're not tied to that. [09:14] Will gladly abandon it. [09:15] jtv!!! [09:15] Still QA? [09:15] StevenK: ? [09:15] wgrant: you will have to [09:15] lifeless: Excellent. [09:15] jtv: You have 4 or 5 branches of QA! [09:15] wgrant: it messes with uites [09:15] lifeless: Should I just use unittests? [09:15] StevenK: no I don't think so [09:15] s/unittests/unittest/ [09:15] wgrant: subunit.run :) [09:15] StevenK: I had to fix an ancient +queue timeout though before I could do meaningful Q/A [09:15] lifeless: Can I integrate that with buildout, or should I just use testr? [09:16] jtv: Sorry, 3. r13302, r13318 and r13326 [09:16] wgrant: I don't know about buildout and tests [09:16] StevenK: I have zero branches in qa-needstesting. [09:16] Your view may be lagging. [09:17] When did you change the bugs? [09:17] pay attention gentlemen [09:17] StevenK: Sometime in the past 4 minutes. [09:17] * StevenK makes a ... sign at bigjools [09:19] lifeless: I am disabling parallel-test again. [09:20] Project parallel-test build #83: ABORTED in 11 hr: https://lpci.wedontsleep.org/job/parallel-test/83/ [09:20] wgrant: chatting with jml for a quick 'how to glue it together' bootstrap may help you [09:20] Because of ^ [09:20] lifeless: Thanks. [09:21] bigjools: pay attention [09:23] lifeless: So we can't use test discovery? [09:23] sure can [09:23] need the discover egg [09:24] How do we make it use OptimisingTestSuite then? [09:24] and a root level load_tests hook to wrap things and reenter into discovery to gather the children [09:24] k [09:24] Will hopefully talk to jml. [09:34] 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] matsubara: hi [09:36] matsubara: I just wanted to check you saw my comment on the bug you incompleted [09:36] lifeless, hello [09:37] matsubara: (because you might not be subscribed ;)) [09:37] lifeless, I have now. thanks [09:37] :) [09:37] lifeless, yeah, I didn't get a mail notification :-) [09:38] hmm I always thought incomplete could be used as a needs info [09:38] if we turn bug expiry off, it could [09:38] but bug expiry *ignores* whether a bug has had a reply [09:38] right, got that. I won't do that anymore [09:39] even if we turned it off, its a bit orthogonal [09:39] we over-conflate things in the status field [09:39] lifeless, btw, do you have an answer to the question I asked there? [09:40] e.g. is-valid, is-bug-or-is-feature-request, is-ready-to-code and filer-has-been-asked-a-question [09:40] matsubara: remind me :) [09:40] 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] lifeless: yes, that's what the BugLifecycle thing is partly aiming to address (or diagnose) [09:40] jml: yes ;) [09:41] matsubara: that would be a good thing to do. I don't think it will eliminate the confusion. It may reduce it. [09:41] matsubara: I don't know if it would be sufficient. [09:41] matsubara: its probably necessary (unless we change the behaviour, which is problematic for a whole other set of issues) [09:43] lifeless, is there other place that documentation could be added? [09:43] theres probably stuff on h.l.n about lists in general [09:45] lifeless, right. [09:45] I'll work on it today [09:46] cool [10:03] 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] jcsackett: i've found some issues with non lazr-js build. am fixing now [10:09] rvba: please use a bigger font :) === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [10:35] bigjools: we'll have to talk about it — I may not fully understand what it is you want [11:28] StevenK: qa-ok! [11:37] huwshimi: hi [11:37] lifeless: Hey there [11:37] so bug 697489 [11:37] <_mup_> Bug #697489: "Participation" and "Involvement" portlets order is different from "applications" links < https://launchpad.net/bugs/697489 > [11:41] huwshimi: how do you want to hae this discussion? [11:41] lifeless: Is here ok? [11:41] its fine by me [11:43] huwshimi: the getting involved portlet shows up on only one page [11:43] huwshimi: I don't see how it can be such a key element [11:44] lifeless: It appears in various forms on project pages, user profiles, bug listings, bugs, answers etc. [11:44] nope [11:44] project and person only AFAICT [11:45] specifically the overview (root domain) view for pillars [11:46] huwshimi: it may have been intended to be widely deployed, but it hasn't been [11:47] lifeless: How do you think most people file a bug? [11:47] huwshimi: apport [11:48] huwshimi: (statistically) [11:48] StevenK: wgrant we should probably meet up tonight to talk about LP [11:48] huwshimi: excluding that special case they use the 'report a bug' link which is visible on bugs.l.n/project [11:48] NCommander: Tonight, ronight? [11:48] s/r/t/ [11:49] huwshimi: log analysis can tell use if folk start from the project front page, but this involvement portlet is new [11:49] lifeless: Right, so that would seem like a pretty important part of the UI to me [11:49] huwshimi: I suspect muscle memory has most folk starting with bugs.l.n/project [11:49] huwshimi: thats a different portlet [11:49] StevenK: well, its tonight, or tomorrow night, and I find that friday nights are less likely to get something done [11:49] huwshimi: isn't it? [11:50] NCommander: Tonight is the LP team dinner [11:50] I'd suggest this afternoon [11:50] StevenK: that works. [11:50] NCommander: Pop your head into the LP breakout room and ask wgrant and bigjools [11:50] 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] StevenK: I'll be over in ~30 minutes [11:51] lifeless: The proposal is that all those portlets would be the same as the main tabs [11:52] lifeless: I don't think it is a bug that they are in a different order [11:53] (a different order to the main tabs) [11:53] huwshimi: I thought the reported defect was that the order was inconsistent [11:54] huwshimi: not that they needed the same content [11:54] lifeless: yes [11:54] lifeless: Are we not saying the same thing? [11:55] I thought for a statement there that you thought the bug was larger than the order [11:55] 'same as the main tabs' [11:55] huwshimi: so I think its fine to say 'the order is different because (reason)' and wontfix it on that basis. [11:56] 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] lifeless: Well the bug merely says they should be the same for "consistency" [11:58] lifeless: There is no data to suggest that that is true either [11:59] well [11:59] there is some research out there, but I don't think its conclusive [11:59] lifeless: Can you point me towards it? [11:59] * lifeless digs [12:00] Nielsen 1989b, http://en.wikipedia.org/wiki/User_interface#Consistency has some references [12:01] lifeless: Oh sorry I thought you meant something specific to this bug [12:02] 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] 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] 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] 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] 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] lifeless: It is a consideration, sure, but not a bug [12:13] huwshimi: curtis also says 'We want one order for all three portlet' [12:13] lifeless: Possibly we don [12:13] *we do [12:14] lifeless: It is not *wrong* that they are different [12:14] huwshimi: being *wrong* is not a necessary condition to be in the tracker [12:15] lifeless: No, that's why we have statuses like "won't fix" [12:15] huwshimi: huh? thats unrelated [12:15] we have wontfix for things we don't want to do. [12:16] lifeless: Right, and I don't think we want to fix this [12:17] lifeless: At least not just for the sake of making it "consistent" [12:18] thats not consistent with what curtis wrote earlier in the bug [12:18] (heh, sorry about the reuse of consistent, brain-broke) [12:20] 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] Thats getting trapped in a local trough [12:20] 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] the aspects of 'would we like this' and 'what is necessary to do it well/acceptably' are quite separatabl [12:21] e [12:23] henninge: The RosettaApplicationView dates back to June 12 2005, and was last seriously touched by SteveA. [12:27] huwshimi: this is dragging on too long [12:27] lifeless: So lets change this to something like opinion then? [12:28] huwshimi: whats your objection to it being open with a caveat about when to do it? [12:28] huwshimi: have I misunderstood you? do you actively want the portlets to have different orders? [12:30] lifeless: It's possible that a different order is actually better [12:30] huwshimi: do we actually think that? curtis said that he wanted them to have the same order eventually [12:31] 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] 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] - which is totally reasonable [12:33] 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] 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] mrevell: I changed 728193 to "In Progress" [12:35] huwshimi: so change this one to say that :) [12:35] lifeless: But I don't think that's really a bug [12:36] I'm getting really confused here [12:37] 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

< https://launchpad.net/bugs/365812 > [12:37] 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] thanks benji [12:37] lifeless: That seems to be more of an opinion thing to actually being a bug [12:38] huwshimi: sure, but its an opinion that the guy which brought in this portlet agrees with [12:39] 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] and I don't understand that [12:40] if you're happy as things are, then cost of change is irrelevant,a nd closing it is appropriate [12:43] 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] huwshimi: if we've committed to doing something about it, closing wontfix (because we are doing X whichmakes redundant) also makes sense [12:45] 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] 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] ah, so this is the meat :) [12:46] huwshimi: do you know why curtis said that we *do* want one order for them all ? [12:47] lifeless: nope [12:47] I suggest you talk to him, since you are both there. [12:48] *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] 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] 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] huwshimi: I'm crashing now before midnight arrives [12:52] lifeless: Ok thanks for that [12:52] 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] unclear bug closing tends to set me off (because of the social impact it has) [12:54] huwshimi: I realise this discussion probably seems a lot larger than you expected when you closed the bug :) [12:55] anyhoo [12:55] night all [12:55] have a great day sprinting [12:56] Night lifeless. [12:59] anyone available for a quick review: https://code.launchpad.net/~matsubara/launchpad/772016-mailinglist-help/+merge/66443? [13:45] wgrant: http://paste.ubuntu.com/635746/ [13:48] 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] wgrant: that's the plan yes. [14:26] sinzui: how does one fire off all YUI tests at once? something with layer=YUI... yeah? [14:34] jcsackett: --layer=YUI should do it. [14:34] thanks wgrant. [14:57] jelmer, thanks for the review! [14:57] matsubara: anytime :) [15:00] StevenK: boo! [15:00] StevenK: will you review https://code.launchpad.net/~benji/launchpad/bug-436247/+merge/66336 for me? [15:00] benji: I could be convinced. Whaddya got? [15:01] * benji hands StevenK ten thousand units of his currency of choice. [15:02] Haha [15:03] benji: My only concern is you drop a tal:define of number_of_dupes [15:03] ooh, looking [15:03] 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] benji: Right, so it was utterly pointless [15:04] absolutely [15:05] benji: r=me [15:05] cool, thanks [15:53] poolie: Give lp:~jml/testtools/gassy-failure-660852 a try if you'd like [16:21] allenap: http://paste.ubuntu.com/634326/ [16:25] StevenK: that was lazr.restfulclient, right? [16:26] benji: Right [16:26] k [16:27] StevenK: I don't see a NEWS.txt entry. What's a good one-line description of the change? [16:27] benji: Best person to ask is poolie. [16:28] * benji sends telepathic waves towards poolie. [16:28] Did they work? :-P [16:28] not yet [16:30] 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] Bad people. No cookie. [16:32] benji: Haha, thank you for sorting it. [16:34] deryck: Do you want to review this branch? https://code.launchpad.net/~huwshimi/launchpad/bug-link-focus-749845/+merge/66474 [16:34] huwshimi, sure. 5 minutes to finish another review, and I'll take a look. [16:34] deryck: np [16:36] wallyworld_, hey. you really here? [16:36] deryck: yes [16:36] sometimes === almaisan-away is now known as al-maisan [16:36] wallyworld_, actually hold on, sorry. taking my advice to jcsackett for a make clean first. [16:36] ok [16:40] wallyworld_, false alarm. works beautifully and diff reports the same files now. [16:40] deryck: \o/ [16:40] wallyworld_, so r=me. [16:40] awesome, thanks [16:41] np [16:41] huwshimi, looking at your MP now. [16:46] huwshimi, come see me about your bug when you can. [16:46] or your MP rather [16:46] deryck: Sure, be there in a few [16:46] huwshimi, cool [16:47] StevenK: ok, 0.12.0 is released [16:47] benji: Thanks! Where can I grab it? [16:48] StevenK: https://launchpad.net/lazr.restfulclient/+download [16:50] thanks jml === beuno is now known as beuno-lunch [17:16] poolie: you might want to try again with the latest branch. I've applied mgz's suggestions. [17:20] huwshimi, http://pastebin.ubuntu.com/635875/ [17:22] deryck: Thanks for that [17:22] deryck: Do you want to approve the branch, or are you ok for me to do it? [17:22] huwshimi, no problem. I added the pastebin to the MP when I approved it just now, too. [17:22] deryck: Ah awesome thatnks [17:22] np [17:22] *thanks [17:28] poolie: If you want to talk about the branch page any more I'm available now [17:29] rvba: lp:~allenap/launchpad/routing-key-generation [17:38] wgrant: http://oo00.eu [17:41] huwshimi, mrevell, would you two like to come and talk about bug workflow with ubuntu people? skaet etc [17:41] up on floor 2 [17:43] poolie: sure, on way === beuno-lunch is now known as beuno [17:59] deryck: re "Big Bang Theory", http://life.metagnome.net/2011/05/crane-transposition.html [17:59] * deryck looks === al-maisan is now known as almaisan-away === salgado is now known as salgado-lunch [18:32] gmb: You appear to have failed to push your lazr.amqp changes. trunk still thinks it's 0.0.2. === salgado-lunch is now known as salgado [20:21] wgrant, ping [20:22] 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] timrc: if you're pushing to a project that has branches private by default, it will be private by default [20:43] dobey, not from my experience [20:43] dobey, at least, not with bzrlib [20:44] bzr is not a private project [20:44] its branches are public by default [20:45] dobey, no, I branched a private branch, made some changes, and pushed a new branch back using bzrlib [20:45] the new branch was public [20:45] timrc, that decision is made by launchpad, not bzr [20:45] so it depends on the location [20:46] pushed to where? [20:46] if you push back to the project with private branches by default, it will be private [20:46] timrc: so you're writing some script that uses bzrlib, and does the pushing/pulling bits? [20:46] dobey, yeah [20:46] maybe it's because the private branch is owned by a user and not a project? [20:47] it shouldn't matter [20:47] projects don't own branches [20:47] a team, rather [20:47] you need to find out if a project has private branches by default or not [20:47] moin [20:47] could be the project does not have private branches by default [20:51] While: [20:51] Installing scripts. [20:51] Getting distribution for 'lazr.amqp==0.1'. [20:51] Error: Couldn't find a distribution for 'lazr.amqp==0.1'. [20:52] this is from attempting a rocketfuel-branch after updating to latest devel today. ideas? [20:55] update your download cache [20:56] yep, I think that did it [20:56] thanks [21:09] I think my problem is that I pushed to +junk ? [21:09] are branches that get pushed to +junk made public? [21:10] timrc: +junk is public [21:10] so this is just my general lack of understanding :) [21:10] timrc: there is /no/ concept of 'is this thing private' for bzr [21:10] timrc: so once you have a local branch, its just like every other branch [21:10] lifeless, this is just a result of my misunderstanding [21:10] timrc: /projects/ in launchpad can define privacy rules [21:14] lifeless, okay [21:46] hrmm [21:46] 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] looks lik a pygments fail [22:07] dobey: file a bug ? [22:12] ok [22:13] against lp, or against... whatever that thing is called that is used for the code browsing? === salgado is now known as salgado-afk [22:21] dobey, loggerhead [22:21] lp [22:21] against loggerhead [22:21] we'll add tasks to loggerhead and a watch to pygments [22:22] beuno: fixed-in-loggerhead isn't fixed-in-lp, so it needs both [22:22] true [22:45] lifeless: O hai. Can I trouble you for a small review? [22:47] of course [22:48] lifeless: https://code.launchpad.net/~stevenk/launchpad/branch-approximatedate/+merge/66480 [22:48] thats reviewed :) [22:49] lifeless: Thanks. I didn't think it would be controversial :-) [22:49] lifeless: As an aside, 'a moment ago' is from the branch I landed a few hours ago [22:49] no worries [22:50] yeah, I like the look of it [22:50] I'm not sure if 10 seconds is the right answer, but it's only mentioned in one place ... [22:55] That test could fail, but if wehave 10 second swap storms stalling the test runner, we have a real problem [22:55] Right [23:00] hows the week been ? [23:01] Tiring [23:01] And in fact, on that note, I'm going to bed. :-) [23:21] * jelmer waves [23:22] jelmer: hi! fixed that bzr-svn bug yet? :) [23:26] mwhudson! [23:26] mwhudson: No, but making progress [23:26] cool [23:26] nice to see some work on loggerhead, too [23:26] mwhudson, I did some manual imports of gcc today to unblock some people [23:27] mwhudson, and I at least have an idea how to manually fix the issue by disabling tags for the moment [23:27] 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] ah [23:27] gcc has ~700 tags [23:27] i can see how that would be a problem for gcc [23:29] 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] ah [23:33] nice software abstractions defeat efficient performance [23:33] or something? [23:34] yeah, though s/nice// because they defeat efficient performance :P [23:35] s/^/seemingly / [23:35] how does one tell a doctest to run in a layer? [23:36] a DocTestSuite specifically [23:36] lifeless: have you encountered test_system_documentation yet? [23:37] probably [23:37] I'll poke at that [23:38] ah, actually i guess lib/lp/$app/test/test_doc.py is the modern equivalent [23:38] (but test_system_documentation is still there too) [23:39] ah [23:39] suite.layer = x [23:40] 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] #bzr might be a better place to ask :) [23:43] lifeless, good point :) [23:43] my brain has married the two projects together :/ [23:45] they're not married, but at least very good friends :)