=== fjlacoste is now known as flacoste [00:36] wallyworld_: are you review bitch today? [00:36] bigjools: depends === wallyworld_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: wallyworld | Firefighting: - | Critical bugs: 3.47*10^2 [00:36] heh [00:37] shame, I was just thinking about lunch at the P&W [00:37] bigjools: i can do that a bit later [00:37] allrighty then [00:41] hey, team bonding is only to occur over approve video conference devices :P [00:46] rick_h_: we can stare at each other through beer glasses, does that count? [00:46] hah, as long as the beer glasses aren't too thick where you get *confused* [01:33] * StevenK stabs stacking more. [01:40] wgrant: when specifying a maintainer for a distro, how often would someone choose a new team that is not in existence yet? [01:43] wallyworld_: Somewhere between never and twice ever, I suspect. [01:43] wallyworld_: For projects it's slightly more relevant, but only barely. [01:44] I would not mourn its loss. [01:44] wgrant: good. because the +reassign page for distros has "this is a new team" choice but the js picker will not have that [02:06] is that the generic "object reassignment" view? [02:07] because that one is pretty good evidence that generic views work well approximately never [02:15] mwhudson: indeed it is [02:59] * wallyworld_ goes to lunch with bigjools [04:14] I can't eat any more of wallyworld_ [04:15] Well, he is full of cholesterol and coffee. [04:17] wgrant: You object to http://pastebin.ubuntu.com/993569/ ? [04:31] StevenK: Probably. [04:31] StevenK: For one thing it's racy. [04:31] The existing stuff was already racy. [04:31] But this is probably worse. [04:32] And it's also not clearly the correct behaviour. [04:36] wgrant: But we can't agree on the correct behaviour. :-( [04:36] Right. [04:37] Probably-buggy implementations of behaviour that hasn't yet been defined are fairly high on my schedule of things to object to. [04:38] But you also object without that change, and you say that there is nothing to discuss. [04:39] The two of us probably can't define what the correct behaviour should be, so just us discussing isn't going to be very helpful :() [05:31] wgrant: There, that should make you slightly happier. [06:55] StevenK: does your current work replace usages of transitively_private eg "if self.source_branch.transitively_private: do something" [07:02] wallyworld_: I don't think so. [07:02] Perhaps it should [07:02] However, that branch is blocked [07:03] StevenK: i am making branchcollection work with information_type. but tests are failing because stuff gets and sets private (and there's no hooks to sync info_type) [07:03] StevenK: so i might add that in my branch then [07:04] wallyworld_: So, I've discovered that an awful lot of code tests just set branch.explicitly_private directly. It's very annoying. [07:04] StevenK: yes, indeed. i'm running into the same thing [07:04] StevenK: i might introduce a mutator [07:04] wallyworld_: That might work. [07:05] StevenK: so if i do this stuff, it won't stomp on your work i hope [07:05] wallyworld_: I'm going to have to redo part of the work anyway, due to the f&%&$*$^$$ stacking discussion [07:05] wallyworld_: I think you basically have to wait for StevenK. [07:05] Due to the stacking thing. [07:06] what stacking thing? [07:06] Neither branch can be deployed until that issue is resolved. [07:06] wallyworld_: Read -dev [07:06] wgrant: You saw it? [07:06] Because information_type doesn't behave like transitively_private yet. [07:06] Yes. [07:06] wgrant: i can deploy my branch because info_type will just be mirroring transitively private [07:06] wallyworld_: The "Branch information_type and stacking" novel on the -dev list, that is. [07:07] wallyworld_: Only if you use a trigger. [07:07] ah right. but behind on my email [07:07] wallyworld_: You can not assume that, since transitively_private is done by trigger and information_type is not. [07:07] Precisely. [07:07] A mutator won't work [07:07] Since it's done behind Python's back. [07:07] sure. i haven't implemented anything yet [07:08] Then don't, and wait for me. [07:08] just finding failures in tests [07:08] well, i've started the branchcollection work. but i'll park that [07:08] * wallyworld_ reads email [07:08] Once we've solved that it should be pretty easy. [07:08] I'll be auditing on Monday, anyway [07:11] wgrant: StevenK: the branchcollectin stuff works, but tests fail due to info_type and private getting out of sync. so i'll come back to that after StevenK does his stuff [07:12] Yup. [07:12] Sounds like a plan. === wallyworld_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 [07:13] Night wallyworld_. [07:13] wgrant: i'm still here. just not ocr :-) [07:14] Ah [07:55] good morning [08:05] morning === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugs: 3.47*10^2 [09:26] jelmer, hi, I see you claimed https://code.launchpad.net/~danilo/launchpad/kill-feedback-requests/+merge/106119: are there any questions you might have about it? [09:32] danilos: hi [09:32] danilos: yes, I started reviewing it yesterday. It seemed pretty straightforward [09:33] danilos: I'll try and finish it today, will ping you if I have any questions. [09:33] jelmer, ok, thanks, just making sure you are not blocked waiting on me or anything :) [09:33] jelmer, sure things, thanks again [09:34] danilos: That'll fail the person merge tests. [09:35] wgrant, it will? because of the DB fields still in? [09:35] danilos: Person merge is required to have explicit handling for any person FK involved in a UNIQUE constraint. [09:35] danilos: You've removed that, so it will complain. [09:35] Normally you land a separate DB patch first which drops the FKs. [09:36] Then you can drop the person merge bits and the rest of the code. [09:36] And once that's deployed you can drop the table. [09:36] wgrant, right, I was hoping to be able to pass with only one DB patch :) [09:36] Sadly not. [09:36] btw, what was the policy, a separate bug for each db-devel landing or can I just reuse the existing bug number? [09:38] Reuse [09:38] ack, thanks [09:43] gmb: Mornin'. Now that your code is in https://code.launchpad.net/~dooferlad/launchpad/upcomingwork_show_incomplete_bp/+merge/105846, should I ask the on-call reviewer to take a look? [09:44] jamestunnicliffe: Yes, that sounds sane. Don't forget to mention danilos's branch w.r.t LoC. I'll have that reviewed this morning. [09:44] gmb, jelmer is on it already :) [09:44] danilos: Ah, cool beans. [09:45] * cjwatson looks very confused at dogfood. I'm sure I've screwed something up, but I don't know what [09:46] dogfood is at r15273; https://dogfood.launchpad.net/+apidoc/devel.html#packageset includes the new relative_build_score property; but: [09:46] $ lp-shell dogfood devel [09:46] ... [09:46] >>> core = lp.packagesets.getByName(name='core') [09:46] >>> core.relative_build_score [09:46] AttributeError: https://api.dogfood.launchpad.net/devel/package-sets/quantal/core object has no attribute 'relative_build_score' [09:46] cjwatson: The WADL's probably old. [09:46] Anyone have any clue what I did wrong? [09:46] Either your cached WADL, or the one on mawson [09:47] mawson seems to have it; how do I clear the local cache? [09:48] ah, let's try nuking this file ... [09:48] Somewhere in ~/.launchpadlib [09:49] It changes :/ [09:49] got it, thanks [09:49] >>> core.relative_build_score [09:49] 0 [10:05] wgrant, fwiw, the following makes person-merge tests pass for me: https://code.launchpad.net/~danilo/launchpad/bug-1000642-db/+merge/106343 [10:15] danilos: Great. [10:18] hum, branch is stuck at "updating branch"; I wonder if that's because I first pushed a branch with no changes compared to db-stable (forgot to commit the patch) [10:18] or if the branch scanner is just being slow (though, it has been pretty quick lately) [10:25] it updated, I guess it was just slow [10:54] jamestunnicliffe, I believe you'll need to request another review on https://code.launchpad.net/~dooferlad/launchpad/upcomingwork_show_incomplete_bp/+merge/105846 [10:55] danilos: I know. I am just attempting to do some more testing, but having a bit of DB trouble. [10:55] jamestunnicliffe, ah, ok :) [12:20] jelmer, thanks for the review, we'll have to wait for the DB patch to land (stub has approved it) before we can land this [12:27] sinzui: is there any reason why the distribution members field is not exported to the webservice like mirror_admin (for example) is? [12:40] wallyworld_, there was never a request to export it. The team does not have power [12:49] sinzui: if it is not exported, the ajax picker can't work [12:49] ha [12:49] it can be exported [12:50] so i would like to wrap the field definition inside exported() === wallyworld is now known as wallyworld_ [12:53] Well [12:53] We could just drop the field instead. [12:53] That would be my preference. [12:58] wgrant, I want to keep it. I would like to add it projects. I would only consider removing it if someone ever implements project team hierarchies AKA project affiliations [12:59] Perhaps. [12:59] But the inconsistency with projects is confusing and silly. [13:04] wgrant, then we give project a members field so that Lp knows that the project has members who are not in an Lp role with power === matsubara-afk is now known as matsubara [13:16] sinzui: Can you look at bug #1001181? [13:16] <_mup_> Bug #1001181: Bug, branch and merge proposal views have large amounts of horizontal overflow in Firefox < https://launchpad.net/bugs/1001181 > [13:20] jelmer, Is there a way to view code imports by VCS type? I can't find one, so I'm guessing not. [13:20] https://code.launchpad.net/+code-imports [13:20] wgrant, It is a regression. Something is creating a very wide invisible something. I suspect help or a overlay which is visibility: hidden [13:21] they still take up space [13:21] sinzui: Yeah, that seems to be the issue. [13:21] I don't know quite which element it is, though. [13:21] mrevell: the code imports page has a way to list them by type [13:21] Perhaps one of the new intermediate divs you added. [13:22] mrevell: e.g. https://code.launchpad.net/+code-imports?field.review_status=&field.review_status-empty-marker=1&field.rcs_type=HG&field.rcs_type-empty-marker=1&submit=Submit [13:22] jelmer, Erk, yes, sorry [13:23] wgrant, I doubt that since the div would be following the existing rules. I think this might relate to the noscript branches I landed. I was going to remove the last Y.ua.ie hack fro our code today. I will solve this regression first [13:23] sinzui: Unless there was a > rule or something. But yeah, could be noscript. [13:31] sinzui: i may have missed you reply - am i ok to export the distro members filed so the ajax picker can work? [13:31] yes [13:33] /msg NickServ identify cuteb89 [14:54] Hi, hopefully someone with good Zope Template foo can help. I need to conditionally add a class to a element. I am not finding anything useful in the docs. [14:58] jamestunnicliffe: i'm not TAL expert, but this *might* work. http://pastebin.ubuntu.com/994317/ [14:58] someone with better TAL foo could probably come up with something better, but it's a start. [15:00] jcsackett and jamestunnicliffe: unfortunately that won't work because it's not well formed. One second, let me see if I can remember the way to do that. [15:00] benji: doh, you're right. [15:01] the best way is probably to just tal:define the class list conditionally and have a single element that uses that definition [15:02] Sounds reasonable. === salgado is now known as salgado-lunch === matsubara is now known as matsubara-lunch === deryck is now known as deryck[lunch] [17:37] Hi, I see that the on call reviewer is offline. What is the protocal at this point? Assign the review to launchpad and let someone claim it/ [17:37] ? [17:39] yeah [17:39] just leave the merge proposal at the defaults [17:39] thx === matsubara-lunch is now known as matsubara === salgado-lunch is now known as salgado === deryck[lunch] is now known as deryck [20:36] deryck: if around, could you please review https://code.launchpad.net/~abentley/maza-lib/basic-auth/+merge/106465 ? [20:50] abentley, sure [21:02] abentley, looks good to me. r=me [21:03] deryck: Thanks. [21:03] abentley, np. and have a nice weekend! I am about to step away now. [21:03] deryck: You too! [21:06] Thanks! [22:06] I have a Code import of the Chromium Git repo. it failed last time, and I am trying again as I see nothing wrong. I tried the SVN repo, but It imported , but I could not branch or browse the code! Anybody else have a problem like this?