[00:39]  * StevenK kicks celebrity_logged_in()
[00:51] <huwshimi> wgrant, wallyworld_: Have either of you seen user research from dan about the manage disclosure mockups (I guess from a while ago)? I'm just trying to track it down
[00:52] <wallyworld_> huwshimi: perhaps. was it an email?
[00:52] <wgrant> I don't think there's much point continuing those at the moment.
[00:53] <huwshimi> wallyworld_: I assume so
[00:53] <huwshimi> wgrant: How come?
[00:53]  * wallyworld_ checks his email
[00:53] <wgrant> huwshimi: Requirements have changed.
[00:53] <huwshimi> wgrant: Really?
[00:54] <wgrant> It's not clear what we're doing now.
[00:54] <huwshimi> wgrant: So the whole manage disclosure pages might be different?
[00:54] <wgrant> Things are sort of on ice.
[00:54] <wgrant> Possibly, yes.
[00:54] <StevenK> Can haz review? https://code.launchpad.net/~stevenk/launchpad/bugtask-userHasPrivileges-nomination/+merge/84041
[00:54] <wgrant> StevenK: How does that affect performance?
[00:55] <huwshimi> wgrant: When did this happen? I got asked over night to get them ready for testing tomorrow
[00:55] <StevenK> wgrant: IBugNomination.cannAprove() is already a dog?
[00:55] <wallyworld_> huwshimi: wgrant: the page will likely not be that different
[00:56] <wallyworld_> the testing should still go ahead
[00:56] <wgrant> huwshimi: A little over 24 hours ago.
[00:56] <huwshimi> wgrant: Oh right
[00:56] <wgrant> It may not be that different. But it quite possibly will be. I guess we might as well continue testing.
[00:56] <huwshimi> ok
[00:56] <wallyworld_> there's been an adjustment to the scope - security bugs need shared conversations, even private ones, hence multipillar private security bugs are allowed
[00:57] <wgrant> Which means that the disclosure overview page can no longer feasibly show an overview of disclosure.
[00:57] <StevenK> wgrant: We already had to look up the product/distribution and {product,distro}series in canApprove() anyway, we're just checking a few more columns in the same tables.
[00:58] <wgrant> StevenK: k
[00:58] <wgrant> StevenK: Hm
[00:58] <wgrant> StevenK: Isn't this wrong?
[00:58] <wgrant> It seems like it will permit bug supervisors to approve.
[00:58] <wgrant> Which is wrong.
[00:59] <StevenK> We don't want that?
[00:59] <wallyworld_> wgrant: i think the md page can still show an overview
[00:59] <wgrant> wallyworld_: It can't.
[00:59] <wgrant> It can show a partial view.
[00:59] <wallyworld_> huwshimi: sent you an email with the info
[00:59] <wallyworld_> sure it can
[00:59] <wgrant> StevenK: No.
[00:59] <wgrant> wallyworld_: How?
[00:59] <StevenK> Bah
[00:59] <wallyworld_> how not?
[00:59]  * StevenK fixes it to check owner
[00:59] <huwshimi> wallyworld_: Awesome, just got it. Thanks for that
[00:59] <StevenK> By hand
[00:59] <wallyworld_> huwshimi: np
[00:59] <wgrant> wallyworld_: We can't join through BugTask.
[01:00] <wgrant> wallyworld_: So we'd have to flatten everything.
[01:00] <wallyworld_> wgrant: why can't we do a union
[01:00] <wgrant> wallyworld_: Hm?
[01:01] <wallyworld_> instead of joining through a single bugtask, why not do the same thing across all the bug tasks (if there are now allowed to be > 1) and union the results
[01:01] <wgrant> If I have a bug for project A shared with project B, project A's disclosure management page has to show all the observers for A and B.
[01:01] <wallyworld_> yep
[01:01] <wgrant> If the disclosure management page knows about bugtasks, ARIWEJOFUWEFIHWEFIUWEF
[01:01] <wallyworld_> and?
[01:01] <wgrant> Also, slow.
[01:01] <wgrant> It's slow enough as it is.
[01:01] <wallyworld_> so we denormalise
[01:02] <wgrant> I went through this two months ago :)
[01:02] <wgrant> It is not pretty.
[01:02] <wgrant> Or usable.
[01:02] <wgrant> At all.
[01:02] <wallyworld_> bottom line is, we've been tasked with providing a solution for a problem our stakeholders want solved, we need to figure out a way to do it
[01:03] <wallyworld_> we may need to compromise on how some things are delivered/reported
[01:03] <wgrant> We don't necessarily need to solve this.
[01:03] <wgrant> It's not clear whether we want disclosure reports for security bugs.
[01:03] <wgrant> Because proprietary projects will probably be forbidden from sharing security bugs.
[01:03] <wallyworld_> what about private security bugs
[01:03] <wgrant> Or having security bugs at all.
[01:04] <wallyworld_> so, if that's the case, then problem solved :-)
[01:04] <poolie> wgrant, like i said, why not just delete the field?
[01:04] <wgrant> poolie: Which field?
[01:04] <poolie> security
[01:04] <wgrant> Ha ha ha.
[01:04] <wgrant> It's not that simple, unfortunately.
[01:04] <poolie> mm
[01:04] <wgrant> Security privacy is now defined to be completely different from normal privacy.
[01:04] <wgrant> s/now/as of yesterday/
[01:05] <wgrant> wallyworld_: Not problem solved.
[01:05] <wgrant> wallyworld_: It still requires a rethink of the UI.
[01:05] <wgrant> wallyworld_: Regardless.
[01:05] <wallyworld_> sure, but shit happens
[01:05] <wallyworld_> we'll come up with something
[01:05] <wgrant> Right, I'm not saying we won't.
[01:05] <wgrant> I'm saying it needs more thought.
[01:05] <wgrant> And work.
[01:05] <wallyworld_> the mockups can stil be tested
[01:05] <wgrant> And that spending time testing mockups that we know won't work is probably silly.
[01:06] <wallyworld_> we aren't spending any more time developing them, but it's still valid to test them
[01:06] <wallyworld_> as is
[01:06] <wallyworld_> since there's other useful feedback we can get
[01:06] <wallyworld_> like the use of the tag paradigm etc
[01:06] <wallyworld_> the location of the delete icon
[01:06] <wallyworld_> etc
[01:07] <StevenK> wgrant: Fixed, diff updated. Ignore the ADMIN_EMAIL addition, I've removed that already.
[01:08] <wgrant> StevenK: Why not add a helper method somewhere that checks if driver privileges are possesed?
[01:08] <wgrant> It would be very similar to userHasPrivileges or whatever the existing thing is.
[01:08] <wgrant> Except without bug supervisor.
[01:09] <wallyworld_> wgrant: StevenK: same me some greping, do either of you know the unit test for viewing a P3A owned by a private team where the use cannot see the team but is subscribed to the P3A?
[01:09] <wallyworld_> /same/save
[01:10] <StevenK> wgrant: Because it probably requires rewritting IBugTask.userHasPrivileges() for the third time in as many branches.
[01:10] <wgrant> StevenK: Good.
[01:10] <wgrant> StevenK: Rewritten but clean is better than dirty.
[01:10] <wgrant> wallyworld_: No idea, sorry.
[01:10] <wgrant> wallyworld_: You can probably find it by following the evil aura, though.
[01:10] <wallyworld_> np. just an opportunistic question just in case
[01:10] <StevenK> wgrant: userHasPrivilegesContextWithBugSupervisor()
[01:11] <wgrant> StevenK: userHasBugSupervisorPrivileges?
[01:11] <wgrant> userHasDriverPrivileges?
[01:11] <poolie> huwshimi,  i have a thing for you
[01:12] <poolie> https://code.launchpad.net/~mbp/launchpad/feature-modulus/+merge/84042
[01:12] <poolie> review pls
[01:18] <flacoste> wgrant, wallyworld_: the discussion between sinzui, mrevell and I was that we think it's fine that manage disclosure only shows a partial view of security issues
[01:18] <flacoste> basically the view of the security policy for your project
[01:19] <wgrant> flacoste: Right. But it gets confusing for projects like U1, which may have both proprietary and security bugs.
[01:19] <flacoste> with a warning saying: some people might have access to some security bugs through other projects
[01:19] <wallyworld_> flacoste: i think that's workable
[01:19] <wgrant> We need to present that somehow that they're different.
[01:20] <huwshimi> poolie: You are awesome :D
[01:21] <poolie> now do something useful with it :)
[01:22] <huwshimi> poolie: Sure will, I just need to build a logging/reporting tool for it :D
[01:22] <wallyworld_> poolie: do you take bribes to allow users to "get in" on the feature :-)
[01:23] <poolie> sounds like a business model to me
[01:23] <flacoste> wgrant: is it really a problem? either these security bugs are really private and they won't share it, or they are security bugs (and say also affect Ubuntu) in which case the warning is good enough
[01:23] <poolie> more seriously you can always have something turned on either by membership in a team or by being lucky with your uid
[01:23] <poolie> or vice versa
[01:23] <wgrant> flacoste: Well, we have to make it clear that it shows everything for one tag, and not everything for the other.
[01:24] <wgrant> Which is confusing, because in the current designs they're shown identically..
[01:24] <flacoste> wgrant: yes, but a simple notice is probably good enough
[01:24] <wgrant> Heh, users don't notice notices.
[01:24] <wgrant> Ever.
[01:24] <flacoste> agreed
[01:25] <wallyworld_> wgrant: you are in "glass half empty"mode today :-P
[01:25] <poolie> today?
[01:25] <StevenK> What poolie said.
[01:25] <flacoste> but the assumption here, which should be tested, is that users have different assumptions between privacy and security
[01:25] <wgrant> flacoste: At present they have the same assumptions, because they behave the same way.
[01:25] <flacoste> so the fact that other people have access through the shared project security policy isn't surprising
[01:25] <flacoste> lke it would be for private bugs
[01:26] <wallyworld_> flacoste: there will be some adjustment to users' thinking when security and privacy an de-conflated, but the overall; result will be much easier to grok i think
[01:26] <flacoste> wallyworld_: that's what sinzui though when I suggested that we keep multi-tenancy around security bugs
[01:26] <flacoste> thought
[01:27] <wallyworld_> flacoste: i liked your email. enum for privacy/visibility with orthogonal security flag
[01:27] <wallyworld_> agree with security bugs being multi-tenanted so conversations can be shared
[01:27] <poolie> huwshimi, let me know howmuch you care about slicing anonymous users
[01:27] <poolie> my impression is they do not have very interesting interactions
[01:28] <wgrant> I don't agree that multi-tenancy is the solution to shared conversations.
[01:28] <poolie> mm
[01:28] <wgrant> But it may be the easiest way out for now.
[01:28] <poolie> i wonder how many non bot requests are anonymous
[01:28] <wgrant> poolie: A quick grep should tell you...
[01:28] <poolie> indeed, i will do that in a sec
[01:28] <flacoste> wgrant: yeah, i can agree with that
[01:28] <poolie> but the real question is do people ever want to run experiments on them
[01:29] <poolie> wgrant, though i wonder too how many anonymous users are also blocking or ignoring cookies...
[01:29] <wgrant> poolie: True.
[01:29] <poolie> we can possibly find that too
[01:29] <wallyworld_> even some non anonymous users block cookies
[01:29] <wallyworld_> well, those who care about privacy
[01:30] <poolie> uh
[01:30] <wgrant> Well, if they're not anonymous to LP they're probably allowing at least one LP cookie :)
[01:30] <poolie> not if they want to sit at the big people's table
[01:30] <wallyworld_> "big people's table"?
[01:30] <poolie> you cannot be both logged in and also blocking lp's own cookies
[01:30] <wallyworld_> wgrant: yeah, sadly i had to add lp to my whitelist
[01:31] <wgrant> wallyworld_: Yeah :(
[01:32] <huwshimi> poolie: I guess we could always build that into into the reporting, there would certainly be some a/b test where we would be targeting logged out users.
[01:32] <poolie> spm i have a thing for you too: https://code.launchpad.net/~mbp/launchpad/feature-admin-party/+merge/84044
[01:32] <poolie> wgrant, would you mind doing a security review of that one?
[01:32] <poolie> it is not very big but it is a little scary
[01:32] <wgrant> Admin party?
[01:32] <wgrant> Aha
[01:32] <poolie> when you first start couchdb, it says "Admin party! Everyone is admin!"
[01:33] <wgrant> There seems to be a false assumption th ere.
[01:33] <wgrant> Why would anyone willingly start couchdb? :)
[01:33] <poolie> *if
[01:34] <wgrant> I'm not sure if we should really do this.
[01:34] <wgrant> We have non-Canonicalers in ~registry, for example.
[01:34] <poolie> istr robert approving it
[01:34] <wgrant> And even Canonicalers aren't always going to be aware of what implications flags have.
[01:34] <poolie> the concept that is
[01:34] <poolie> perhaps ~registry is the wrong thing
[01:34] <wgrant> (there are security-influencing flags)
[01:35] <StevenK> wgrant: Diff updated.
[01:36] <poolie> i think we should probably be careful about putting really dangerous things in there
[01:36] <poolie> in the first place
[01:36] <lifeless> mmm
[01:37] <wgrant> StevenK: DriverPrivileges and PrivilegesContext?
[01:37] <poolie> i guess making it a specific group would let us flip this at run time
[01:37] <poolie> without a boostrapping problem
[01:37] <wgrant> StevenK: We probably want BugSupervisorPrivileges(Context)? and DriverPrivileges(Context)?.
[01:39] <poolie> lifeless, what do you think?
[01:41] <poolie> i had the idea it had a preimp approval
[01:42] <lifeless> poolie:  https://bugs.launchpad.net/launchpad/+bug/790025/comments/1 is all I had said
[01:42] <_mup_> Bug #790025: provide LP developers full access to QAS/Staging feature flags <canonical-losa-lp> <feature> <feature-flags> <Launchpad itself:Triaged> < https://launchpad.net/bugs/790025 >
[01:43] <spm> poolie: heh, scratching an itch there?
[01:43] <poolie> i was going to do the userslice thing when i was offline yesterday and then i remembered this
[01:44] <lifeless> poolie: I think there are two issues; A) there is a code structure issue, which I've reviewed. B) there is the how-to-enable-it
[01:44] <poolie> and yeah, it does seem like somewhat unnecessary manual handoffs
[01:44] <StevenK> wgrant: PrivilegesContext is the current name and is still called everywhere
[01:45] <poolie> yeah
[01:46] <poolie> there are some precedents for the inline permission check
[01:46] <poolie> but not necessarily good ones
[01:49] <poolie> lifeless, so if it's hooked in differently and it is enabled by adding people to eg ~admin-features-rules
[01:49] <poolie> that would be acceptable?
[01:50] <lifeless> poolie: are you proposing admin-feature-rules as a celebrity ?
[01:51] <poolie> i guess effectively yes
[01:51] <poolie> i understand some of the machinery around celebtrities is disliked?
[01:52] <poolie> it depends a bit how much you expect to want to change it dynamically
[01:53] <lifeless> so the thing about celebrities that is disliked is largely the fact that its a well known team.
[01:54] <lifeless> so avoiding the rest of the machinery but blessing a team name will just get the bad stuff without mitigating it via the other supporting code
[01:54] <poolie> ok
[01:54] <poolie> so what is the actually preferred place for configuration?
[01:54] <poolie> or rather policy
[01:54] <lifeless> zcml or lazr.conf or feature flags
[01:55] <poolie> i hear config is disliked, zcml is disliked, embedding it in the code is disliked
[01:55] <lifeless> are the three generic places we have
[01:55] <lifeless> or schema things hanging off of objets
[01:55] <lifeless> theres no 'site' or 'instance' object in the db today
[01:58] <poolie> hm
[01:58] <poolie> what defines who has a particular permission on a particular object?
[01:59] <lifeless> the security adapters
[02:02] <poolie> hm
[02:03] <poolie> so i see there are things that grant some permissions if user.in_launchpad_developers
[02:03] <poolie> s/things/adapters
[02:05] <poolie> perhaps i'll leave  it, it was more of a drive by attempt
[02:09] <wgrant> StevenK: The callsites can and should be changed...
[02:09] <wgrant> It's a pretty trivial refactoring across part of one codebase, which will result in cleaner, more maintainable code.
[02:10] <wgrant> lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-ce9f40e4e0a1507f99c1f0eda494ae39
[02:13] <lifeless> wgrant: win!
[02:13] <wgrant> Rather.
[02:14] <lifeless> a unicode string
[02:14] <lifeless> wtf
[02:14] <lifeless> wgrant: care to file a bug for me? I'll add a codepath to type-handle this
[02:15] <lifeless> also someone should shoot the zope machinery
[02:17] <poolie> lifeless, is there enough value in  pulling out the DemoSite fixture?
[02:18] <lifeless> afk -> bank visit, bbsoonish
[02:51] <huwshimi> wallyworld_: In those prototypes is the "Add an observer" link for adding a privacy observer?
[02:51] <huwshimi> or security as well?
[02:51] <wallyworld_> huwshimi: it adds the person ad both atm
[02:52] <wallyworld_> as
[02:52] <wallyworld_> from there you can use the popups to change
[02:52] <wallyworld_> but we need to enahnce the picker
[02:52] <huwshimi> wallyworld_: That seems suboptimal.
[02:52] <wallyworld_> yes, the picker needs to be enhanced
[02:53] <wallyworld_> but we didn't want to do that for the mockup - ran out of time
[02:53] <huwshimi> sure, just checking
[02:54] <wallyworld_> np
[02:55] <huwshimi> wallyworld_: Also the 10	users can view project information
[02:55] <huwshimi> 6	users are observers
[02:55] <huwshimi> 5	users are restricted observers
[02:55] <huwshimi> block seems to be a little redundant as it doesn't cater for security/privacy
[02:55] <huwshimi> Not sure what to do with that
[02:55] <huwshimi> Is it actually useful for anything?
[02:56] <wallyworld_> those numbers are now used to represent users who have any sort of permission (security or privacy or ...)
[02:57] <huwshimi> wallyworld_: I guess that info can now be determined by using the filters
[02:57] <huwshimi> wallyworld_: And jumbling the stats together as they are now doesn't seem useful (but tell me if I'm wrong)
[02:57] <wallyworld_> yes, but the portlet is useful because it shows users with *any* observer access for example
[02:57] <wallyworld_> but that's just my opinion
[02:58] <wallyworld_> as a project owner, that's what i'd want to see
[02:58] <huwshimi> wallyworld_: is that useful if you don't know if they can only see apport bugs or something?
[02:59] <wallyworld_> of course we'd add that into the nav portlet in the final version
[02:59] <wallyworld_> what's there now is based on the original screenshots before these new things were thought of
[03:00] <huwshimi> wallyworld_: Right, that's why I'm trying to determine how this should look now that we have that new info
[03:01] <wallyworld_> ok :-)
[03:01] <huwshimi> (btw I'm doing a whole new set of mockups, so this isn't me asking you to do anything at this point).
[03:03] <huwshimi> "of course we'd add that into the nav portlet in the final version" <- what is "that" in this sentence?
[03:04] <wallyworld_> the summary  of number of apport bugs and "quicklink"
[03:04] <wallyworld_> (and any other quicklinks deemed necessary)
[03:05] <huwshimi> wallyworld_: So there would be a list of each "tag" with the number of observers/restricted observers?
[03:05] <wallyworld_> perhaps. that's what i would want to see as a user
[03:06] <wallyworld_> sort of a shortcut to using the search form
[03:06] <wallyworld_> but that may not be feasible for the number of tags we have
[03:06] <wallyworld_> it's really up to the users to ask for what they want in that portlet
[03:07] <wallyworld_> ah, scratch that comment about number of tags
[03:08] <wallyworld_> the portlet has roles (observer, restricted observer)
[03:08] <wallyworld_> plus any other shortcuts we want to add
[03:08] <wallyworld_> or are asked to add
[03:08] <StevenK> wgrant: Have another look?
[03:10] <wgrant> StevenK: It seems sort of odd to call it as a method on a bugtask, but still have to pass the context in manually.
[03:11] <StevenK> wgrant: I have no choice -- the main call sites don't have a BugTask.
[03:11] <wgrant> StevenK: That's why there was a separate *Context method before.
[03:13] <StevenK> wgrant: You'd like me to duplicate the current methods to Context and context-less versions?
[03:14] <wgrant> StevenK: Yes. The implicit context version of userHasBugSupervisorPrivileges seems to already exist, but it's called userHasPrivileges.
[03:16] <lifeless> poolie: I think showing the evaluated flag values is ok; just the scopes are the issue.
[03:55] <huwshimi> wgrant, wallyworld_: In the prototype where it says "Subscribed to 6 bugs and 4 branches" is "subscribed to" the right wording there?
[03:56] <wgrant> No.
[03:56] <wallyworld_> nope
[03:56] <wgrant> "subscribed" is wrong.
[03:56] <wgrant> It's not clear what the right wording is.
[03:56] <wallyworld_> the wording is/was true to the originally supplied screenshots
[03:56] <wgrant> I want to dump "observer" and say "access" or something instead.
[03:57] <lifeless> private things shared with you
[03:57] <wallyworld_> "access" sounds ok for now i think
[03:57] <lifeless> isn't that the concept ?
[03:57] <wallyworld_> yes, but we need a single word or two
[03:57] <lifeless> 'shared with'
[03:57] <wgrant> huwshimi: Where in the prototype does it say this?
[03:57] <wgrant> I haven't looked for a while.
[03:57] <lifeless> also why are we showing counts.
[03:58] <huwshimi> wgrant: http://people.canonical.com/~ianb/disclosure/
[03:58] <wallyworld_> 'shared with' sounds ok
[03:58] <wallyworld_> counts? as per the original screenshots
[03:58] <wallyworld_> i personally like them
[03:58] <lifeless> which original screenshots ?
[03:58] <wallyworld_> i would want to see them as a user
[03:58] <wgrant> So, showing the counts outside the context of a particular policy probably doesn't make sense.
[03:59] <wallyworld_> the balsalmiq ones from 18 months ago
[03:59] <wallyworld_> not sure who did them
[03:59] <wgrant> I still suggest [Proprietary: everything] [Security: 2 bugs, 4 branches] or something like that.
[03:59] <huwshimi> I was thinking the heading could be changed to "Disclosed bugs and branches" and the the content could just be the count "6 bugs and 4 branches"
[03:59] <wgrant> Kills off the column, and destroys the probably deliberately obscure "observer" terminology.
[03:59] <wallyworld_> that works
[03:59] <lifeless> rule of thumb: showing precise counts is expensive. Unless it matters, don't.
[03:59] <huwshimi> is that doing too much for a summary though?
[04:00] <lifeless> in this case, what matters is that you can click to expand the user/team and see what they have access to.
[04:00] <wallyworld_> i guess it's up to the users whether it matters
[04:00] <lifeless> I don't see how the exact count matters.
[04:00] <lifeless> (after all, its potentially wrong as soon as we render the page :))
[04:00] <wallyworld_> as i user i'd want some indication, perhaps not an exact count
[04:01] <wallyworld_> sure, and so are amazon stock counts on their order page
[04:01] <wgrant> lifeless: As an OEM project manager, I need to grant a distro engineer access to one of my bugs, to get their expertise.
[04:01] <wallyworld_> but they still show them
[04:01] <lifeless> wgrant: then you need to know that their access is restricted.
[04:01] <wgrant> On the disclosure management page, I want to be able to see that he doesn't have access to 2000 bugs.
[04:02] <wallyworld_> actually, shopping sites normally show < 5 in stock or > 5 in stock or whatever
[04:02] <huwshimi> wgrant: But how do we show that without an exact count?
[04:02] <wallyworld_> so not exact counts
[04:02] <lifeless> wallyworld_: right, because thats all that matters to the user: can they make a reasonable order and get instant delivery.
[04:02] <wallyworld_> i think we need some indication, but not exact if it's expensive
[04:02] <lifeless> wgrant: so do you want a whiteboard to say 'this engineer should only access branch X' ?
[04:02] <lifeless> wgrant: how will the project managers coordinate things?
[04:03] <lifeless> anyhow, if the schema can do it brilliantly-fast, thats cool. It just sets off alarm bells every time I see this.
[04:03] <wgrant> lifeless: Note that "the schema" is now invalid :/
[04:05] <wallyworld_> tales question - <div tal:repeat foo=somefoos tal:condition foo.somecheck/> - fails because foo is not yet defined for the condition check
[04:05] <wallyworld_> what's the best way to get around this?
[04:06] <wallyworld_> i guess i need to use a nested div
[04:07] <lifeless> foo is a collection ?
[04:07] <huwshimi> So, do we want the "Disclosed bugs and branches" column and if so what will the content be if it's not exact counts?
[04:07] <lifeless> sorry, somefoos is ?. anyhow, the condition runs before the loop
[04:08] <wallyworld_> somefoos is pseudo code. bugger about conditiob running before loop
[04:08] <wallyworld_> i'll have to rework the tales
[04:08] <wallyworld_> i want the condition on each item in the loop
[04:09] <wallyworld_> huwshimi: we want the column with approx counts i reckon
[04:10] <huwshimi> wallyworld_: How do you represent an approx count?
[04:11] <wallyworld_> that's for you as ui designer to tell us :-P
[04:11] <StevenK> "~ 4 branches" ?
[04:11] <wallyworld_> or perhaps "< 10" or ">10"
[04:11] <huwshimi> wallyworld_: Right, but I have no idea what an approx count is
[04:11] <huwshimi> wallyworld_: Ok, thanks
[04:12] <lifeless> one of the reasons I was challenging the column is that it will get long
[04:12] <lifeless> bugs
[04:12] <lifeless> branches
[04:12] <wallyworld_> 10 is arbitrary
[04:12] <lifeless> milestones
[04:12] <lifeless> series
[04:12] <lifeless> blueprints
[04:12] <lifeless> answers
[04:12] <huwshimi> wallyworld_: So we can get the database to return roughly what the user can see?
[04:12] <lifeless> will all eventually be assets accounted for
[04:13] <lifeless> huwshimi: we can ask it to estimate, it sometimes is spooky accurate, and sometimes heinously wrong
[04:13] <wallyworld_> lifeless: can postgres return approx counts efficiently? i think so, based on previous irc conversations?
[04:13] <huwshimi> lifeless: Ah great. Thanks
[04:13] <lifeless> it can return the plan estimate
[04:13] <wallyworld_> but it would be accurate for small numbers no? like > 10 or < 10 ?
[04:13] <lifeless> sometimes
[04:13] <huwshimi> wallyworld_: but would we no whether it was >10 or <10?
[04:14] <huwshimi> wallyworld_: or just ~10
[04:14] <wallyworld_> not sure
[04:14] <huwshimi> *know
[04:14] <wallyworld_> i don't think it matters
[04:14] <wallyworld_> i would just want to know if my exposure to that user is big or small
[04:14] <huwshimi> wallyworld_: Well it matters in how we represent it
[04:14] <wallyworld_> to catch situations like wgrant described above
[04:15] <wallyworld_> hmmm
[04:15] <huwshimi> wallyworld_: 10, >10 and <10 are all very different things
[04:16] <wallyworld_> yes. i don't think we need "10" though.
[04:16] <wallyworld_> i would want to know < some number or > some number
[04:17] <huwshimi> maybe we should kill this column and if people want to know what the user can see they have to view the person/team details
[04:17] <huwshimi> cause >10 is really a meaningless number to represent
[04:17] <wallyworld_> perhaps, especially if it expands to more than bug and branches
[04:17] <wallyworld_> > 10 is not meaningless - it depends on what you want to know
[04:18] <huwshimi> wallyworld_: well it is meaningless if the exact number is 2,000
[04:18] <wallyworld_> ie have you accidentally allow the user to see more than just the 1 or 2 branches you assigned them to
[04:18] <huwshimi> wallyworld_: I know in reality the estimation won't be that far off, but the user doesn't know that
[04:18] <wgrant> Er
[04:18] <lifeless> huwshimi: it may be that far off
[04:18] <wgrant> The estimation may be orders of magnitude off.
[04:18] <lifeless> huwshimi: approx *really is* approx
[04:18] <huwshimi> lifeless: Oh
[04:18] <lifeless> the accuracy depends a great deal on how complex the query is
[04:19] <huwshimi> lifeless: OK, thanks that helps make the decision :)
[04:19] <wallyworld_> lifeless: is it accurate for 0 or not 0?
[04:19] <lifeless> wallyworld_: no
[04:19] <wallyworld_> wtf?
[04:19] <wgrant> It doesn't use indices.
[04:19] <lifeless> wallyworld_: 0 is not special cased
[04:19] <wgrant> It uses randomly gathered stats.
[04:19] <wallyworld_> weird design then
[04:19] <lifeless> wallyworld_: row count is just a vector, how many rows it thinks will be returned.
[04:20] <lifeless> wallyworld_: it may think that 3 rows will be returned for a query that returns none
[04:20] <wallyworld_> ok. i don't like postgres anymore then
[04:20] <lifeless> wallyworld_: theres no possible way it can know a priori that nothing*can* be returned unless it executes the query
[04:23] <lifeless> wgrant: did your previous schema report counts efficiently?
[04:24] <wgrant> In my late schema it isn't denormed, but it's only through one join and row counts will be low unless people are doing stupid things.
[04:25] <wgrant> I didn't try getting counts on Ubuntu-scale data.
[04:25] <wgrant> But I could.
[04:25] <wgrant> Not that it's going to be immensely useful, because the schema has to change.
[04:25] <lifeless> why ?
[04:25] <wgrant> Probably adding an intermediate table between APA and AP.
[04:25] <wgrant> Because we need multiple policies per artifact.
[04:25] <lifeless> ELOST
[04:26] <wgrant> We must support multi-pillar private security bugs.
[04:26] <wgrant> Therefore we cannot have a single policy per bug.
[04:26] <wgrant> Therefore APA.policy cannot be.
[04:31] <StevenK> wgrant: And another look?
[04:42] <poolie> (back)
[04:42] <poolie> lifeless, re your comment above, my branch does still show the active values, just not the scopes that caused them
[04:42] <lifeless> cool
[04:47] <StevenK> wgrant: Do you want to actually scribble on this MP, or shall I bug the OCR?
[04:48] <wgrant> StevenK: Looking right now, actually.
[04:48] <wgrant> Sorry, been distracted in -ops and stuff
[04:49] <wgrant> Approved
[04:50] <StevenK> wgrant: Thanks, tossing at ec2.
[05:34] <StevenK> check_permission('launchpad.View', team) in a view magically looks up the user, or am I Doing It Wrong?
[05:35] <poolie> stevenk i think it does use the current user
[06:00] <wgrant> StevenK: It uses the user from the current request.
[06:12] <poolie> lifeless, maybe we can make the 404 page just more obvious?
[06:12] <poolie> that won't fix everything but it will help the common case
[06:16] <poolie> nm actually
[06:55] <lifeless> stub: so, catchup time ?
[07:25] <stub> lifeless: sure
[08:54] <bigjools> morning
[09:04] <nigelb> Morning bigjools :)
[09:10] <adeuring> good morning
[11:42] <nigelb> Hi, can I have the launchpad task removed from this bug? bug 884610
[11:42] <_mup_> Bug #884610: Change the attendee in +temp-meeting-export <Launchpad itself:Triaged by nigelbabu> <Summit:New> < https://launchpad.net/bugs/884610 >
[11:42] <nigelb> It seems we can solve this in summit itself and patching launchapd isn't necssary.
[11:43] <rvba> allenap: I know you're busy right now but can you add this MP to your queue? https://code.launchpad.net/~rvb/launchpad/private-ppa-bug-890927-2/+merge/84083
[11:43] <allenap> rvba: Sure can :)
[11:43] <allenap> nigelb: I'll have a look
[11:44] <bigjools> I already removed it
[11:44] <nigelb> \o/
[11:44] <nigelb> Thanks!
[11:44] <allenap> bigjools: That would have been my first bugtask deletion ;-(
[11:44] <bigjools> allenap: lol, sorry.  It was my 2nd :)
[11:44] <allenap> :)
[11:45] <rvba> allenap: I spoke with Gary about this so maybe he will be willing to have a look too.
[11:45] <bigjools> I think I did the first one in prod when it went live
[11:45] <nigelb> Thanks you guys *so* much for this feature :)
[11:45] <nigelb> So many unnecessary bugtasks lying around :)
[11:46] <rvba> allenap: I've been force to monkey patch a view in a test… I really don't know why that is because the view in question is created via an url that exists.
[11:46] <rvba> forced even
[11:47] <allenap> rvba: I am intrigued...
[12:06] <gmb> Oh, how I love developing with trusted.sql
[12:12] <nigelb> Somehow I think its infactuation and not *real* love ;)
[12:23] <gmb> nigelb: Possibly. I use it in the same way as I would use the phrase "Oh, how I love slamming the car door on my fingers in the morning."
[12:23] <nigelb> gmb: Heh
[13:16] <bigjools> is there anyone around who knows anything about the code importer?
[13:16] <jelmer> bigjools: somewhat
[13:17] <jelmer> bigjools: what's up with the code importer?
[13:22] <bigjools> jelmer: trying to find out why it ran out of memory on a certain date/time
[13:23] <bigjools> the logs are somewhat obtuse
[13:27] <bigjools> jelmer: a worker was killedby an admin is it was hitting swap, I am trying to find out which worker, which branch etc
[13:28] <mhall119> can someone tell me the URL for the Launchpad XMLRPC service where I can call isTeamPublic?
[13:28] <mhall119> I'm trying to test the public teams access controll for launchpad lists
[14:08] <abentley> adeuring, rick_h_: with deryck away, do you want to do the standup in 22 minutes or 1:22?
[14:10] <rick_h_> abentley: either works for me
[14:15] <adeuring> abentley, rick_h_: let's wait for deryck
[14:16] <abentley> adeuring: In other words, you want to hold the stand-up in the North American afternoon?
[14:16] <adeuring> abentley: it's still afternoon for me too ;)
[14:17] <abentley> adeuring: Even the morning is after the previous day's noon :-)
[14:18] <adeuring> abentley: right ;) But 4:30 pm local time is still pretty early for me
[14:19] <abentley> adeuring: cool.
[14:19] <abentley> adeuring: Did you want any more help with the work you're doing?
[14:19] <adeuring> abentley: no, thanks, I'm making some slow progress
[14:19] <abentley> adeuring: okay.
[14:32] <sladen> bzr log -r 14418..14419
[14:32] <sladen> is that doing the opposite to what what poolie was working on with Like!/+1 etc?
[14:36] <rvba> sladen: indeed. Our technical architect has spoken: external js/css is now verboten.
[14:48]  * nigelb hugs james_w 
[15:00] <sladen> rvba: sur gut
[15:11] <abentley> mrevell: I have some questions about getting rid of the hot bug listings.  Do you have time for a chat?
[15:25] <allenap> jcsackett: Thanks for the Approved.
[15:26] <jcsackett> allenap: you're welcome.
[15:29] <mrevell> abentley, I do at around 17.00 UTC, if that's any good.
[15:29] <abentley> mrevell: sure, let's do that.
[15:29] <mrevell> Great.
[16:17]  * mrevell has been on the Launchpad team five years today :)
[16:18] <rick_h_> mrevell: congrats?
[16:19] <rick_h_> or hould we be sending bottles to a certain address?
[16:20] <mrevell> https://launchpad.net/~launchpad-dev/+mailing-list-subscribers
[16:20] <mrevell> oops
[16:20] <mrevell> danhg, ^^^
[16:20] <mrevell> rick_h_, Yeah, congrats definitely :) And bottles would be lovely, haha
[16:22] <Ursinha> mrevell: congrats! :)
[16:22] <mrevell> Thanks Ursinha :)
[16:36]  * bigjools shakes mrevell's hand
[17:03] <abentley> mrevell: chat?
[17:04] <abentley> mrevell: sure.
[17:04] <mrevell> thanks
[17:07] <mrevell> abentley, Does Skype work for you?
[17:07] <abentley> mrevell: sure.
[17:18] <mrevell> abentley, https://dev.launchpad.net/Projects/CustomBugListings/Design
[18:07] <lifeless> morning
[18:11] <deryck> abentley, ping.
[18:32] <abentley> deryck: pong
[18:33] <deryck> abentley, hey, don't have long to chat since rick_h_ and I are sharing a sprint room, but he's lunching.  shall we mumble?
[18:33] <abentley> deryck: let's.
[18:41] <abentley> deryck: https://dev.launchpad.net/Projects/CustomBugListings/Design
[19:05] <abentley> deryck: I figured it out: registry/browser/configure.zcml sets +bug-index as the default, but bugs/browser/configure.zcml actually defines +bug-index.  Never seen those done in separate place before.
[19:06] <deryck> abentley, ah!  great, thanks.
[19:07] <sinzui> abentley, bug is all messed up by bugtask
[19:07] <abentley> sinzui: I don't understand.
[19:07] <sinzui> abentley, I favour deleting all bug domain entries from registry
[19:08] <abentley> sinzui: me too.  I'll do what I can.
[19:08] <sinzui> abentley, sorry I misread the location of the configure.zcml
[19:11] <abentley> sinzui: Does moving the browser:defaultView entries for BugsLayer out of registry/browser/configure.zcml sound good to you?
[19:11] <sinzui> yes please
[19:12] <abentley> sinzui: great.
[19:26] <abentley> deryck: there's no way of feature-flagging this change, but I think even non-beta users will be pleased by it.
[19:34] <abentley> mrevell, deryck: Another point in favour of a single display rather than configuring between two-row/one-row is that widescreen users may alternate between half-width and full-width browsers.
[21:16] <wallyworld_> sinzui: i have to drive my wife to work today and will be absent at standup. could we have a chat now?
[21:16] <sinzui> yes
[21:32] <wallyworld_> jcsackett: hi, i just saw the email about the mockups. i can make the changes today if you haven't already
[21:37]  * wallyworld_ runs away to drive wife to work. back soon
[21:53] <rick_h_> deryck: http://uploads.mitechie.com/lp/lp_spinner_indicator.png
[22:51] <jcsackett> wallyworld_: indeed, i didn't get to said mockup changes. however, if you don't manage to get much done on that front today I should be able to tackle them tomorrow.
[22:52] <wallyworld_> jcsackett: shouldn't take too long. i'll let you know if i don't get it done
[22:52] <jcsackett> wallyworld_: dig.
[23:34] <wallyworld_> sinzui: there's currently no protection around icon in the team tales formatter; the icon is always rendered. so i don't think we need a test for that
[23:36] <wallyworld_> same with logo from what i can tell
[23:50] <wgrant> lifeless: Any objection to letting team admins promote other admins?
[23:51] <wgrant> (with a view to abolishing team owners eventually)
[23:52] <lifeless> given that delegated operation of teams is a feature, yes.
[23:52] <lifeless> letting team admins promote other admins I have no intrinsic objection to.
[23:53] <wgrant> We can't abolish ownership without separating member/admin, right.
[23:53] <lifeless> perhaps I wasn't clear
[23:53] <lifeless> abolishing ownership is undesirable
[23:53] <wgrant> Why?
[23:53] <lifeless> 'delegated operation of teams is a feature'
[23:53] <wgrant> Assuming you can be an admin without being a member, why do we need an owner?
[23:57] <lifeless> are you saying 'there are no differences between owners and admins if admins can promote themselves' ?
[23:58] <wgrant> No.
[23:58] <wgrant> If we change the current fact that admin privileges imply membership, the only benefit ownership provides is that it can't be revoked by the other admins.
[23:59] <wgrant> (as well as confusing people to death, and introducing obscure special cases in our and others' code)