[00:36] <bigjools> wallyworld_: are you review bitch today?
[00:36] <wallyworld_> bigjools: depends
[00:36] <bigjools> heh
[00:37] <bigjools> shame, I was just thinking about lunch at the P&W
[00:37] <wallyworld_> bigjools: i can do that a bit later
[00:37] <bigjools> allrighty then
[00:41] <rick_h_> hey, team bonding is only to occur over approve video conference devices :P
[00:46] <bigjools> rick_h_: we can stare at each other through beer glasses, does that count?
[00:46] <rick_h_> hah, as long as the beer glasses aren't too thick where you get *confused*
[01:33]  * StevenK stabs stacking more.
[01:40] <wallyworld_> wgrant: when specifying a maintainer for a distro, how often would someone choose a new team that is not in existence yet?
[01:43] <wgrant> wallyworld_: Somewhere between never and twice ever, I suspect.
[01:43] <wgrant> wallyworld_: For projects it's slightly more relevant, but only barely.
[01:44] <wgrant> I would not mourn its loss.
[01:44] <wallyworld_> 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] <mwhudson> is that the generic "object reassignment" view?
[02:07] <mwhudson> because that one is pretty good evidence that generic views work well approximately never
[02:15] <wallyworld_> mwhudson: indeed it is
[02:59]  * wallyworld_ goes to lunch with bigjools
[04:14] <bigjools> I can't eat any more of wallyworld_
[04:15] <StevenK> Well, he is full of cholesterol and coffee.
[04:17] <StevenK> wgrant: You object to http://pastebin.ubuntu.com/993569/ ?
[04:31] <wgrant> StevenK: Probably.
[04:31] <wgrant> StevenK: For one thing it's racy.
[04:31] <wgrant> The existing stuff was already racy.
[04:31] <wgrant> But this is probably worse.
[04:32] <wgrant> And it's also not clearly the correct behaviour.
[04:36] <StevenK> wgrant: But we can't agree on the correct behaviour. :-(
[04:36] <wgrant> Right.
[04:37] <wgrant> Probably-buggy implementations of behaviour that hasn't yet been defined are fairly high on my schedule of things to object to.
[04:38] <StevenK> But you also object without that change, and you say that there is nothing to discuss.
[04:39] <wgrant> 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] <StevenK> wgrant: There, that should make you slightly happier.
[06:55] <wallyworld_> StevenK: does your current work replace usages of transitively_private eg "if self.source_branch.transitively_private: do something"
[07:02] <StevenK> wallyworld_: I don't think so.
[07:02] <StevenK> Perhaps it should
[07:02] <StevenK> However, that branch is blocked
[07:03] <wallyworld_> 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] <wallyworld_> StevenK: so i might add that in my branch then
[07:04] <StevenK> wallyworld_: So, I've discovered that an awful lot of code tests just set branch.explicitly_private directly. It's very annoying.
[07:04] <wallyworld_> StevenK: yes, indeed. i'm running into the same thing
[07:04] <wallyworld_> StevenK: i might introduce a mutator
[07:04] <StevenK> wallyworld_: That might work.
[07:05] <wallyworld_> StevenK: so if i do this stuff, it won't stomp on your work i hope
[07:05] <StevenK> wallyworld_: I'm going to have to redo part of the work anyway, due to the f&%&$*$^$$ stacking discussion
[07:05] <wgrant> wallyworld_: I think you basically have to wait for StevenK.
[07:05] <wgrant> Due to the stacking thing.
[07:06] <wallyworld_> what stacking thing?
[07:06] <wgrant> Neither branch can be deployed until that issue is resolved.
[07:06] <StevenK> wallyworld_: Read -dev
[07:06] <StevenK> wgrant: You saw it?
[07:06] <wgrant> Because information_type doesn't behave like transitively_private yet.
[07:06] <wgrant> Yes.
[07:06] <wallyworld_> wgrant: i can deploy my branch because info_type will just be mirroring transitively private
[07:06] <StevenK> wallyworld_: The "Branch information_type and stacking" novel on the -dev list, that is.
[07:07] <wgrant> wallyworld_: Only if you use a trigger.
[07:07] <wallyworld_> ah right. but behind on my email
[07:07] <StevenK> wallyworld_: You can not assume that, since transitively_private is done by trigger and information_type is not.
[07:07] <wgrant> Precisely.
[07:07] <wgrant> A mutator won't work
[07:07] <wgrant> Since it's done behind Python's back.
[07:07] <wallyworld_> sure. i haven't implemented anything yet
[07:08] <StevenK> Then don't, and wait for me.
[07:08] <wallyworld_> just finding failures in tests
[07:08] <wallyworld_> well, i've started the branchcollection work. but i'll park that
[07:08]  * wallyworld_ reads email
[07:08] <wgrant> Once we've solved that it should be pretty easy.
[07:08] <StevenK> I'll be auditing on Monday, anyway
[07:11] <wallyworld_> 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] <wgrant> Yup.
[07:12] <wgrant> Sounds like a plan.
[07:13] <wgrant> Night wallyworld_.
[07:13] <wallyworld_> wgrant: i'm still here. just not ocr :-)
[07:14] <wgrant> Ah
[07:55] <adeuring> good morning
[08:05] <czajkowski> morning
[09:26] <danilos> 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] <jelmer> danilos: hi
[09:32] <jelmer> danilos: yes, I started reviewing it yesterday. It seemed pretty straightforward
[09:33] <jelmer> danilos: I'll try and finish it today, will ping you if I have any questions.
[09:33] <danilos> jelmer, ok, thanks, just making sure you are not blocked waiting on me or anything :)
[09:33] <danilos> jelmer, sure things, thanks again
[09:34] <wgrant> danilos: That'll fail the person merge tests.
[09:35] <danilos> wgrant, it will? because of the DB fields still in?
[09:35] <wgrant> danilos: Person merge is required to have explicit handling for any person FK involved in a UNIQUE constraint.
[09:35] <wgrant> danilos: You've removed that, so it will complain.
[09:35] <wgrant> Normally you land a separate DB patch first which drops the FKs.
[09:36] <wgrant> Then you can drop the person merge bits and the rest of the code.
[09:36] <wgrant> And once that's deployed you can drop the table.
[09:36] <danilos> wgrant, right, I was hoping to be able to pass with only one DB patch :)
[09:36] <wgrant> Sadly not.
[09:36] <danilos> btw, what was the policy, a separate bug for each db-devel landing or can I just reuse the existing bug number?
[09:38] <wgrant> Reuse
[09:38] <danilos> ack, thanks
[09:43] <jamestunnicliffe> 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] <gmb> 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] <danilos> gmb, jelmer is on it already :)
[09:44] <gmb> 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] <cjwatson> dogfood is at r15273; https://dogfood.launchpad.net/+apidoc/devel.html#packageset includes the new relative_build_score property; but:
[09:46] <cjwatson> $ lp-shell dogfood devel
[09:46] <cjwatson> ...
[09:46] <cjwatson> >>> core = lp.packagesets.getByName(name='core')
[09:46] <cjwatson> >>> core.relative_build_score
[09:46] <cjwatson> AttributeError: https://api.dogfood.launchpad.net/devel/package-sets/quantal/core object has no attribute 'relative_build_score'
[09:46] <wgrant> cjwatson: The WADL's probably old.
[09:46] <cjwatson> Anyone have any clue what I did wrong?
[09:46] <wgrant> Either your cached WADL, or the one on mawson
[09:47] <cjwatson> mawson seems to have it; how do I clear the local cache?
[09:48] <cjwatson> ah, let's try nuking this file ...
[09:48] <wgrant> Somewhere in ~/.launchpadlib
[09:49] <wgrant> It changes :/
[09:49] <cjwatson> got it, thanks
[09:49] <cjwatson> >>> core.relative_build_score
[09:49] <cjwatson> 0
[10:05] <danilos> wgrant, fwiw, the following makes person-merge tests pass for me: https://code.launchpad.net/~danilo/launchpad/bug-1000642-db/+merge/106343
[10:15] <wgrant> danilos: Great.
[10:18] <danilos> 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] <danilos> or if the branch scanner is just being slow (though, it has been pretty quick lately)
[10:25] <danilos> it updated, I guess it was just slow
[10:54] <danilos> 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] <jamestunnicliffe> danilos: I know. I am just attempting to do some more testing, but having a bit of DB trouble.
[10:55] <danilos> jamestunnicliffe, ah, ok :)
[12:20] <danilos> 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] <wallyworld_> sinzui: is there any reason why the distribution members field is not exported to the webservice  like mirror_admin (for example) is?
[12:40] <sinzui> wallyworld_, there was never a request to export it. The team does not have power
[12:49] <wallyworld_> sinzui: if it is not exported, the ajax picker can't work
[12:49] <sinzui> ha
[12:49] <sinzui> it can be exported
[12:50] <wallyworld_> so i would like to wrap the field definition inside exported()
[12:53] <wgrant> Well
[12:53] <wgrant> We could just drop the field instead.
[12:53] <wgrant> That would be my preference.
[12:58] <sinzui> 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] <wgrant> Perhaps.
[12:59] <wgrant> But the inconsistency with projects is confusing and silly.
[13:04] <sinzui> 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
[13:16] <wgrant> 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 <javascript> <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1001181 >
[13:20] <mrevell> jelmer, Is there a way to view code imports by VCS type? I can't find one, so I'm guessing not.
[13:20] <wgrant> https://code.launchpad.net/+code-imports
[13:20] <sinzui> 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] <sinzui> they still take up space
[13:21] <wgrant> sinzui: Yeah, that seems to be the issue.
[13:21] <wgrant> I don't know quite which element it is, though.
[13:21] <jelmer> mrevell: the code imports page has a way to list them by type
[13:21] <wgrant> Perhaps one of the new intermediate divs you added.
[13:22] <jelmer> 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] <mrevell> jelmer, Erk, yes, sorry
[13:23] <sinzui> 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] <wgrant> sinzui: Unless there was a > rule or something. But yeah, could be noscript.
[13:31] <wallyworld> sinzui: i may have missed you reply - am i ok to export the distro members filed so the ajax picker can work?
[13:31] <sinzui> yes
[13:33] <wallyworld>  /msg NickServ identify cuteb89
[14:54] <jamestunnicliffe> Hi, hopefully someone with good Zope Template foo can help. I need to conditionally add a class to a <tbody> element. I am not finding anything useful in the docs.
[14:58] <jcsackett> jamestunnicliffe: i'm not TAL expert, but this *might* work. http://pastebin.ubuntu.com/994317/
[14:58] <jcsackett> someone with better TAL foo could probably come up with something better, but it's a start.
[15:00] <benji> 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] <jcsackett> benji: doh, you're right.
[15:01] <benji> the best way is probably to just tal:define the class list conditionally and have a single <tbody> element that uses that definition
[15:02] <jamestunnicliffe> Sounds reasonable.
[17:37] <jamestunnicliffe> 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] <jamestunnicliffe> ?
[17:39] <cjwatson> yeah
[17:39] <cjwatson> just leave the merge proposal at the defaults
[17:39] <jamestunnicliffe> thx
[20:36] <abentley> deryck: if around, could you please review https://code.launchpad.net/~abentley/maza-lib/basic-auth/+merge/106465 ?
[20:50] <deryck> abentley, sure
[21:02] <deryck> abentley, looks good to me.  r=me
[21:03] <abentley> deryck: Thanks.
[21:03] <deryck> abentley, np.  and have a nice weekend!  I am about to step away now.
[21:03] <abentley> deryck: You too!
[21:06] <deryck> Thanks!
[22:06] <kendfinger> 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?