| jelmer | poolie: upstream-2.5.0~beta1+bzr6182 | 00:03 |
|---|---|---|
| StevenK | wgrant: Can I say <tal:block tal:condition="blah" replace="" /> ? | 00:08 |
| wgrant | StevenK: replace="" sounds pretty useless, but yes. | 00:09 |
| StevenK | wgrant: replace="foo", but okay, thanks. | 00:09 |
| * StevenK needs a test first. | 00:09 | |
| * StevenK shakes fist at TDD. | 00:09 | |
| poolie | james_w, don't suppose you're here? | 00:09 |
| poolie | ok https://bugs.launchpad.net/bzr-builder/+bug/885497 | 00:10 |
| poolie | wgrant: i think i will try to do that whole series of tweaks to buildd, including making it slightly testable, and then ask for that to be deployed | 00:17 |
| poolie | since it is expensive, atomic, and independent of lp deployments it seems better to batch it | 00:17 |
| wgrant | Yep. | 00:18 |
| lifeless | poolie: one thing that would be brilliant is to remove it from the LP tree | 00:19 |
| lifeless | poolie: this requires creating two small projects - one to hold the current common code, and one to hold the buildd production code. | 00:19 |
| lifeless | you don't have to, but its in the same space you're looking at. | 00:19 |
| poolie | ok, i'll consider that | 00:20 |
| poolie | i'll see what is common | 00:20 |
| poolie | classic case of it hard to bootstrap out of being hard/scary to change | 00:20 |
| lifeless | readyservice should be the entirety | 00:20 |
| poolie | hahah | 00:20 |
| poolie | another classic example of that: | 00:20 |
| poolie | the bug we hit was fixed in june | 00:20 |
| poolie | (885497) but we've been trying to deploy since then so it is not on the buildd today | 00:21 |
| wgrant | Oh, so we're using a bzr-builder snapshot from months ago? | 00:21 |
| poolie | we're using a snapshot from years ago | 00:21 |
| poolie | (on prod today) | 00:22 |
| wgrant | s/using/upgrading to/ | 00:22 |
| poolie | yeaoh | 00:22 |
| jelmer | wgrant: it was the release I did back when I started trying to get a newer bzr-builder on the buildds | 00:22 |
| wgrant | Right :( | 00:22 |
| poolie | it's ok | 00:22 |
| lifeless | these consistently make me sad - empty diffs : https://code.launchpad.net/~lifeless/python-oops-tools/amqp-polish/+merge/81083 | 00:24 |
| wgrant | lifeless: You pushed and merged around the same time? | 00:24 |
| poolie | https://bugs.launchpad.net/launchpad/+bug/854520 | 00:25 |
| lifeless | wgrant: I pushed, clicked approved and tarmac ran | 00:25 |
| wgrant | Right. | 00:25 |
| wgrant | And MPJ is crap. | 00:26 |
| wgrant | So it didn't run until the merge was done. | 00:26 |
| jelmer | poolie: --allow-fallback-to-native | 00:30 |
| poolie | ftr: ah ok so this is not totally fixed upstream, it just gives a cleaner error | 00:30 |
| jelmer | poolie: actually, we shouldn't need a newer bzr-builder at all | 00:44 |
| jelmer | just the --allow-fallback-to-native flag should be sufficient | 00:44 |
| jelmer | the improved error message is only shown when that flag isn't present | 00:44 |
| jelmer | not any newer than what we have in cat-proposed at the moment, that is | 00:45 |
| poolie | how about the one that's in production now? | 00:47 |
| jelmer | poolie: that doesn't have some of the new features required for bfbia and new debversion variables people have asked for | 00:49 |
| jelmer | in particular, the one currently in production can create non-native packages | 00:49 |
| wallyworld_ | wgrant: StevenK: what's your recollection of the direction being taken for private team name visibility? are private team names still to be hidden when required? | 00:51 |
| poolie | right but it will be safe to pass --allow-fallback to that as an interim step? | 00:54 |
| poolie | i know it needs tobe updated, i'm just wondering if it needs to be serialized or synchronized with the buildd changes | 00:54 |
| jelmer | poolie: older versions don't support --allow-fallback-to-native so will probably blow up if it is specified | 00:59 |
| jelmer | poolie: we will need to update launchpad-buildd and bzr-builder at the same time | 00:59 |
| poolie | ok | 01:03 |
| StevenK | Hm. team.addMember() is returning a tuple that contains TeamMembershipStatus.INVITED. Do I have to do anything to that to make it show up? | 01:18 |
| wgrant | StevenK: The invitation needs to be accepted. | 01:19 |
| wgrant | Or possibly do it as an LP admin. | 01:20 |
| StevenK | I'm doing it in a with celebery_logged_in block | 01:20 |
| wgrant | Sounds like you need to do the invitation acceptance dance anyway, then. | 01:20 |
| * StevenK was looking for an example of that, and came up empty-handed. | 01:22 | |
| wallyworld_ | StevenK: you doing the addMember() in a test? | 01:22 |
| StevenK | wallyworld_: Indeed. | 01:23 |
| wallyworld_ | StevenK: use makeTeam(members=[xxxx]) | 01:23 |
| wallyworld_ | with name=xxxx as well of course | 01:23 |
| StevenK | wallyworld_: Where do I send the cake? | 01:25 |
| wallyworld_ | give it to spm. he needs it more than i do :-) | 01:26 |
| StevenK | Haha | 01:26 |
| spm | rofl | 01:26 |
| spm | dunno about "need", want, yes. need, not so much. :-) | 01:26 |
| wallyworld_ | well, need == want for some levels of want :-) | 01:26 |
| StevenK | need == want for sufficently high levels of want | 01:27 |
| wallyworld_ | yes, that's more accurate | 01:27 |
| wallyworld_ | or, in javascript: need === want | 01:27 |
| StevenK | https://launchpad.dev/~super doesn't even show Subteam of when not logged in :-( | 01:45 |
| StevenK | Perhaps it needs to be restricted | 01:45 |
| wgrant | Is super a subteam? | 01:46 |
| wgrant | Sounds more like a superteam to me. | 01:46 |
| StevenK | http://pastebin.ubuntu.com/726885/ | 01:47 |
| StevenK | Possibly badly named | 01:47 |
| StevenK | Right, it does need to be restricted | 01:57 |
| poolie | huwshimi: how about if we talk now about fonts and markup? | 02:45 |
| huwshimi | poolie: Sure | 02:45 |
| poolie | here, mumble, ..? | 02:45 |
| huwshimi | poolie: Don't mind, whatever is easiest | 02:46 |
| poolie | mumble! | 02:46 |
| huwshimi | sure | 02:47 |
| lifeless | u | 02:57 |
| lifeless | can has review ? https://code.launchpad.net/~lifeless/launchpad/bug-885303/+merge/81106 | 02:57 |
| wgrant | lifeless: Want to trade? https://code.launchpad.net/~wgrant/launchpad/observer-db/+merge/81104 | 02:59 |
| wgrant | Not exactly equal, but I did do that 3kline one for you last week :P | 02:59 |
| wgrant | lifeless: How about quickly hacking oops-tools to accept the ID in the path rather than query string, to work around apache-openid? | 03:02 |
| lifeless | wgrant: I have some critical path stuff to finish, like the rsync replacing script | 03:04 |
| lifeless | wgrant: remind me next week | 03:04 |
| wgrant | Bah | 03:04 |
| lifeless | I'm not sure quite whats involved, I'm sure it will be a little fiddly given my lack of know-how on django internals. | 03:05 |
| lifeless | If I thought it was 5 minutes, I'd do it now. | 03:05 |
| spm | wgrant: you did it wrong. <wgrant> lifeless: it's impossible to hack oops-tools to accept the ID in the path rather than query string, to work around apache-openid. so don't worry about it. we'll just mark a bug and ignore it. <== fixed | 03:05 |
| wgrant | Heh | 03:06 |
| lifeless | wgrant: your cover letter confuses me a little | 03:06 |
| wgrant | lifeless: Good. | 03:06 |
| lifeless | third paragraph | 03:06 |
| lifeless | Permissions can be either policy-global or artifact-specific. In the first case APP.artifact is left unset, | 03:06 |
| lifeless | letting the permission holder see all artifacts under the policy. | 03:06 |
| wgrant | lifeless: What is confusing? | 03:07 |
| wgrant | lifeless: Why'd you remove the "Check against false positives" test? | 03:08 |
| lifeless | do you mean grants when you say permissions ? | 03:08 |
| lifeless | what does policy-global mean | 03:08 |
| lifeless | what is APP | 03:08 |
| lifeless | who is the permission holder? | 03:08 |
| wgrant | Well, they are grants, yes. | 03:09 |
| wgrant | s/policy-global/policy-wide/ | 03:09 |
| wgrant | APP == AccessPolicyPermission | 03:09 |
| wgrant | Permission holder == APP.person | 03:09 |
| lifeless | how do you feel about s/Permission/Grant/ | 03:09 |
| wgrant | I was following an existing pattern (eg. ArchivePermission), but sure. | 03:10 |
| lifeless | that one weirds me out too ;) | 03:11 |
| lifeless | perhaps I've spent too long with SQL | 03:12 |
| lifeless | wgrant: are you doing a pillar table still ? | 03:13 |
| wgrant | lifeless: Possibly. | 03:14 |
| wgrant | Not sure if it's worth it. | 03:14 |
| huwshimi | poolie: https://bugs.launchpad.net/launchpad/+bug/30002 | 03:15 |
| wgrant | It's easy to work in if you want me to. | 03:15 |
| lifeless | shrug :). | 03:15 |
| lifeless | was just curious | 03:15 |
| wgrant | lifeless: Oh, I see now why you removed the test. | 03:16 |
| wgrant | lifeless: Should we mandate the hyphen? | 03:16 |
| wgrant | Otherwise anyone talking about oopses is going to get linkified. | 03:16 |
| wgrant | Which would be bad. | 03:16 |
| lifeless | oops foo ? | 03:16 |
| lifeless | I don't really see a use case for OOPS 123asd123 | 03:16 |
| wgrant | Right. | 03:16 |
| lifeless | since we hyphenate it everywhere. | 03:16 |
| wgrant | So mandate the hyphen. | 03:16 |
| lifeless | WFM | 03:16 |
| wgrant | Otherwise anybody mentioning "oops" in a sentence will get linkified. | 03:17 |
| lifeless | also | 03:17 |
| lifeless | OOPS - 12345 | 03:17 |
| lifeless | shouldn't link IMNSHO | 03:17 |
| wgrant | Well, depends on word-wrapping. | 03:17 |
| lifeless | ugh | 03:17 |
| lifeless | sure | 03:17 |
| lifeless | hates on that though. | 03:17 |
| wgrant | Yes. | 03:17 |
| wgrant | I'm reminded of the numbered lists with one item ending in "bug" case. | 03:17 |
| poolie | lifeless: my discussion with huw is on hold but is mostly up to looking for a compromise width that is roughly (but no less than) 80 monospace cells | 03:21 |
| lifeless | cool | 03:21 |
| wgrant | lifeless: Thanks. | 03:23 |
| lifeless | my branch has its new commit up. | 03:25 |
| wgrant | lifeless: You want a note in the AccessPolicyArtifact comment about adding new types there? | 03:25 |
| lifeless | wgrant: somewhere | 03:25 |
| lifeless | wgrant: something that says 'this is how its meant to stick together' | 03:25 |
| lifeless | wgrant: a memo for yourself in 3 years time | 03:25 |
| wgrant | k | 03:25 |
| huwshimi | wgrant, wallyworld_: Right, so with the security stuff, basically we need to show who has access to security bugs. | 03:28 |
| huwshimi | wgrant, wallyworld_: I gather a team or a user can have access? | 03:28 |
| wallyworld_ | huwshimi: yes, a team or user or user via their team memberships | 03:29 |
| wgrant | huwshimi: Security is going to stop being a special case. | 03:29 |
| wgrant | huwshimi: Projects will have multiple access policies. | 03:29 |
| wgrant | Each private bug or branch has a policy assigned. | 03:29 |
| wgrant | Security bugs would be under the Security policy. | 03:30 |
| wgrant | Non-security but private bugs could be under the Private policy. | 03:30 |
| lifeless | wgrant: can you note to sinzui that https://help.launchpad.net/Bugs/PrivateBugs#Private_bugs implies everyone gets private-by-default bugs | 03:30 |
| wgrant | Each policy has a different set of observers. | 03:30 |
| wgrant | lifeless: Yeah, was going to bring that up next time we had a call. | 03:30 |
| wgrant | Or throw the bug at him. | 03:30 |
| wallyworld_ | wgrant: yes, but security bugs still have the security checkbox ticked, so users still see that and wan to know who has access to such bugs | 03:31 |
| wgrant | wallyworld_: Right, but the policies behave the same way. | 03:31 |
| wgrant | It's no longer a separate role in the project. | 03:31 |
| wgrant | To which only one person or team has access. | 03:31 |
| huwshimi | wgrant, wallyworld_: So Matthew said this: "The manage disclosure page currently shows people who have access to private stuff but we realised today we also need some way of showing people who have access to security bugs. We treat security and private issues separately as they often have to be seen by different people." | 03:31 |
| wallyworld_ | so perhaps we need a view to show what artifacts can be seen under each policy | 03:31 |
| wgrant | huwshimi: Right. | 03:31 |
| wgrant | huwshimi: There will be two separate classes of private objects. | 03:31 |
| huwshimi | wgrant: Is that no longer valid? | 03:31 |
| wgrant | huwshimi: With the same set of controls. | 03:31 |
| wgrant | huwshimi: It is mostly valid. | 03:32 |
| lifeless | wgrant: btw, bugsummary will need an update for this too | 03:32 |
| lifeless | wgrant: though I expect you knew that. | 03:32 |
| wgrant | huwshimi: It will eventually be more than just private and security. It is expected that projects will be able to define their own policies in future. | 03:32 |
| wgrant | lifeless: Yes, lots of stuff does :/ | 03:32 |
| wallyworld_ | huwshimi: so if there were a listing where one could select the user and then select a policy and it would show what a user can see under that policy, would that help? | 03:32 |
| huwshimi | So in the UI we will still need to distinguish between them | 03:33 |
| wallyworld_ | and one of the policies would be security | 03:33 |
| wallyworld_ | huwshimi: i mistyped a bit above. what i meant was choose a policy and then see who can access stuff | 03:34 |
| huwshimi | wallyworld_: tight | 03:34 |
| huwshimi | *right | 03:34 |
| wgrant | lifeless: It's a bit sad that the first significant change to be done through fastdowntime is probably the biggest, most awkward model shift in Launchpad's production history. | 03:34 |
| lifeless | wgrant: you're landing the soyuz un-refactoring finally? | 03:34 |
| wgrant | Hah | 03:35 |
| wallyworld_ | huwshimi: so at the moment, we have a user centric listing ie what can a user see. sounds like we need another new page for policy centric listing | 03:35 |
| lifeless | see what I did thar? | 03:35 |
| wgrant | wallyworld_: I'm imagining something maybe sort of like the AJAX filtering on +localpackagediffs. | 03:36 |
| huwshimi | wallyworld_: I think Matthew was talking about adding that to the filters | 03:36 |
| wgrant | wallyworld_: So the main listing lists all permissions for the project. | 03:36 |
| wallyworld_ | yes | 03:36 |
| lifeless | wgrant: going to approve my mp ? | 03:36 |
| wallyworld_ | the main overview page would be the union of all polocies | 03:36 |
| wgrant | wallyworld_: With rows like "Some Team | Security (observer), Private (restricted observer)" | 03:36 |
| wgrant | And then the AJAX filter widget on the second column. | 03:36 |
| wgrant | Allowing you to select a subset of policies to care about. | 03:37 |
| wgrant | Like the packagsets column on https://launchpad.net/ubuntu/precise/+localpackagediffs | 03:37 |
| wgrant | lifeless: Once the diff's updated. Which it probably is by now. | 03:37 |
| * wallyworld_ loks | 03:37 | |
| wallyworld_ | looks | 03:37 |
| huwshimi | wgrant: Can they have security and private? | 03:38 |
| lifeless | there is no need for non-ajax rendering in this policy page: its modern browsers only stuff | 03:38 |
| lifeless | and not googlebot visible | 03:38 |
| wgrant | huwshimi: Hm? | 03:38 |
| huwshimi | wgrant: Can a teams policy for viewing a private bug be because they can view private and security bugs | 03:39 |
| * huwshimi may not be using the right terminology | 03:39 | |
| lifeless | huwshimi: the bug will be categorised as either private or security | 03:39 |
| lifeless | huwshimi: thats a link to the policy | 03:39 |
| wallyworld_ | wgrant: that filter popup is yucky | 03:39 |
| wallyworld_ | there's no way to "select all" again | 03:39 |
| wgrant | wallyworld_: Yes, but I think the concept's good. | 03:39 |
| wallyworld_ | +1 | 03:40 |
| wgrant | This is also not dissimilar to what Bugs is doing, I expect. | 03:40 |
| lifeless | huwshimi: so they will be able to view a given bug (asset) because they have a grant in the matching policy | 03:40 |
| wgrant | s/Bugs/bug-columns/ | 03:40 |
| wgrant | lifeless: approved, thanks. | 03:40 |
| wallyworld_ | lifeless: i wasn't planning on not doing ajax only :-) | 03:41 |
| lifeless | wgrant: oh, I forgot one hting | 03:41 |
| lifeless | wgrant: why not name column ? | 03:41 |
| lifeless | wgrant: s/not/no/ | 03:42 |
| lifeless | wgrant: for identification in the API - url traversal etc | 03:42 |
| wallyworld_ | huwshimi: there will initially be only out-of-the-box polices, hard wired | 03:42 |
| wallyworld_ | huwshimi: and the meanings or what they allow to be seen will be well explained | 03:43 |
| wallyworld_ | huwshimi: do you have enough to take back to matthew? | 03:45 |
| huwshimi | wallyworld_: I'm just uploading a mockup to see if what I'm doing makes sense | 03:45 |
| wgrant | lifeless: It's not a very linkable thing, so I decided I didn't care much about pretty URL. Display name is a unique reference for use in the API. I can add a name if you want, but it's awkward since we don't autogenerate them. | 03:46 |
| wallyworld_ | huwshimi: i will likely not have enough time to change the current mockup to add in the policy stuff before the next planned testing | 03:46 |
| lifeless | wgrant: we don't ? | 03:47 |
| lifeless | wgrant: I mean, with 2 hard coded policies, they have fixed values | 03:47 |
| huwshimi | wallyworld_: I think Matthew just wants something to show some people at UDS | 03:47 |
| lifeless | wgrant: and private (name) Private (display name) | 03:47 |
| wgrant | lifeless: True, and I guess we do have precedent for interactively autogenerating on ProductSet:+new | 03:47 |
| wgrant | OK, will add. | 03:47 |
| wallyworld_ | i think we need a name FWIW | 03:48 |
| huwshimi | wallyworld_ wgrant: http://people.canonical.com/~huwshimi/policy.png | 03:48 |
| lifeless | wgrant: I see you decided on per-project rows rather than site-wide rows | 03:48 |
| huwshimi | wallyworld_, wgrant: Does that make any sense? | 03:48 |
| lifeless | wgrant: thats fine with me - what led you to that conclusion ? | 03:48 |
| wgrant | huwshimi: Not exactly. It's possible for me to be an Observer for Private, and a Restricted Observer for Security. | 03:49 |
| wallyworld_ | huwshimi: we only want the policy column | 03:49 |
| wallyworld_ | the policy defines what the user can see | 03:49 |
| wgrant | wallyworld_: Oh? | 03:49 |
| wgrant | wallyworld_: There's still an observer/restrictedobserver concept, within each policy. | 03:50 |
| wallyworld_ | wgrant: yes | 03:50 |
| wallyworld_ | i was thinking it was part of the policy but yes, it is separate | 03:50 |
| wgrant | lifeless: Nothing very strongly either way. It's possible that if we want to keep retargeting easy it'll be easier to have site-wide policies, but eeeh. | 03:51 |
| wgrant | lifeless: But it's cheap enough to switch either way later. | 03:52 |
| wgrant | Even with fastdowntime.; | 03:52 |
| lifeless | wallyworld_: hi | 03:52 |
| wallyworld_ | wgrant: huwshimi: it will be difficult to represent the policy/permission concept concisely in a table row | 03:52 |
| wallyworld_ | o/ | 03:52 |
| lifeless | wallyworld_: your recent branches on filtering look broken to me - why are you changing browser code for model issues ? | 03:52 |
| wgrant | wallyworld_: I don't see a better way than "Some Team | Private (observer), Security (restricted observer)" | 03:53 |
| lifeless | wallyworld_: If I may suggest, this is code that doesn't need to be written at all, if you do the proposed partial disclosure of private teams, which I know sinzui has scheduled somewhere | 03:53 |
| wgrant | Unless we assume that people have a reasonable number of policies and turn each into a column. | 03:53 |
| huwshimi | wgrant: Oh, now I understand, you can have different permissions for different policies | 03:54 |
| wallyworld_ | lifeless: that's where the current filtering is done, i just added to the existing filter condition | 03:54 |
| lifeless | wallyworld_: its a different sort of filtering | 03:54 |
| wallyworld_ | lifeless: i see you point about the partial p team disclosure. wonder why the bug was raised then | 03:54 |
| lifeless | bugs :) | 03:55 |
| wallyworld_ | i raised the 2nd one | 03:55 |
| wgrant | huwshimi: Right. eg. someone could have access to all of Ubuntu's Private bugs, and then report a Security bug. They need access to that Security bug, and all Private bugs, but not the rest of the Security bugs. | 03:55 |
| wallyworld_ | based on the first | 03:55 |
| lifeless | kk | 03:56 |
| wgrant | lifeless: I think I should still keep UNIQUE (pillar, display_name), as there's no reason the pillar owners can't keep their own display names unique? | 03:56 |
| lifeless | anyhow, just a thought... your team will be fixing up the fallout one way or another :) | 03:56 |
| lifeless | wgrant: two words: social attacks. | 03:56 |
| wgrant | lifeless: If the project owner is launching a social attack, the project is in trouble anyway... | 03:57 |
| wallyworld_ | lifeless: i think the filtering is messed up then. "private and user_can_edit" also belongs in the model in that case | 03:57 |
| lifeless | wgrant: not on themselves :P | 03:57 |
| lifeless | wallyworld_: one of the first things I noted when I became TA is that we have too much code in our browser classes ;) | 03:57 |
| wgrant | lifeless: So, should I keep the UNIQUE or not? | 03:57 |
| wallyworld_ | lifeless: agree 1000% | 03:58 |
| lifeless | wgrant: I think the UNIQUE has to stay. | 03:58 |
| wallyworld_ | the privacy setting and event raisng stuff in the browser is total bollocks | 03:58 |
| lifeless | wgrant: on name and separately on display name. | 03:58 |
| wallyworld_ | for example | 03:58 |
| wgrant | lifeless: Right, that's what I had done. Thanks. | 03:58 |
| wallyworld_ | lifeless: i was merely taking a pragmatic view to tweak what was already there | 03:59 |
| lifeless | wgrant: I'm just noting that editing is perhaps a problem (unless we show Private (private)) | 03:59 |
| lifeless | wallyworld_: you may not be aware of this, but bug subscription calculations are a big chunk of rendering a bug | 03:59 |
| wgrant | lifeless: Given that the namespace is controlled by the project owner and display_name is UNIQUE, that should be unnecessary. | 03:59 |
| lifeless | wallyworld_: so you want to be confident you're not triggering late evaluation when touching this stuff :) | 04:00 |
| lifeless | wgrant: retargeting | 04:00 |
| wgrant | lifeless, wallyworld_: I'm not sure if it's changed since stub's fixes last night, but yesterday the bug subscription queries made up like 80% of bug render time. | 04:00 |
| huwshimi | wgrant, wallyworld_: Like this then? http://people.canonical.com/~huwshimi/policy2.png | 04:00 |
| lifeless | wgrant: and in future linking probably | 04:00 |
| wallyworld_ | lifeless: i sort of knew. hence the desire not to mess with the existing stuff at a lower level also. i am almost certain that the permission check will not add any late eval but could do a test i suppose | 04:01 |
| wgrant | lifeless: I'm not sure how that's relevant. You're only going to be seeing policies from one project. If you can't trust the owner of that project, you can't safely assign the bug there at all. | 04:01 |
| wgrant | huwshimi: Indeed. | 04:01 |
| lifeless | wallyworld_: anyhow, even if its moved to the model, it will still be wrong | 04:02 |
| lifeless | wallyworld_: because we want to show the subscribers | 04:02 |
| lifeless | wallyworld_: having hidden subscribers is a defect | 04:02 |
| lifeless | wallyworld_: (consider someone replying to a bug notification email, who is a hidden subscriber...) | 04:02 |
| huwshimi | wallyworld_: Does that mockup make sense to you too? | 04:03 |
| wallyworld_ | lifeless: sure, but at the moment it oopses | 04:03 |
| wallyworld_ | and until now, private team visibility was verboten | 04:03 |
| lifeless | wallyworld_: its a soft oops added by StevenK to track places that need updating | 04:03 |
| StevenK | In fact, I'm fixing one now. | 04:04 |
| StevenK | Or attempting to, rargh! | 04:04 |
| StevenK | Bloody tests. | 04:05 |
| wallyworld_ | lifeless: i didn't try the ui, just wrote the test, are you saying ui will render ok, just with "<hidden team>" as the display name? | 04:05 |
| lifeless | wallyworld_: yes | 04:05 |
| lifeless | wallyworld_: thats the status quo | 04:05 |
| StevenK | *And* it will throw a MixedVisibility OOPS. | 04:05 |
| StevenK | So fix it. | 04:05 |
| lifeless | wallyworld_: the fix is to a) tell folk we're changing this and b) show the team display name, name and url. | 04:05 |
| lifeless | StevenK: has the policy change been communicated yet ? | 04:05 |
| StevenK | lifeless: I have no idea. | 04:05 |
| lifeless | StevenK: just fix it isn't useful if we're not ready to change things | 04:06 |
| wallyworld_ | lifeless: so to do (b) we need to change the zope permissions, no? | 04:06 |
| StevenK | Curtis filed a bug saying we shouldn't show private teams under Subteam of | 04:06 |
| wallyworld_ | and he filed the bug i did the mp for, same issue sort of | 04:06 |
| lifeless | I think something has gotten confused then | 04:07 |
| james_w | poolie, am now | 04:07 |
| huwshimi | wallyworld_: Just wanted to check you were happy that the second mockup made sense before I spend to much time fixing up all the other mockups | 04:07 |
| StevenK | wallyworld_: Then link lifeless the bug | 04:07 |
| StevenK | Easy solution | 04:07 |
| wallyworld_ | huwshimi: sorry, just one sec | 04:07 |
| lifeless | as that is diametrically opposed to the plan in e.g. | 04:07 |
| lifeless | bug 855670 | 04:07 |
| huwshimi | wallyworld_: No problems :) | 04:07 |
| poolie | hi james_w, i think it's all sorted | 04:08 |
| lifeless | wallyworld_: and bug 405277 | 04:08 |
| * wallyworld_ looking | 04:08 | |
| james_w | good good | 04:08 |
| james_w | how is everyone today? | 04:08 |
| poolie | good | 04:09 |
| poolie | are you at uds? | 04:09 |
| poolie | i was going to show you https://bugs.launchpad.net/launchpad/+bug/885497 | 04:10 |
| lifeless | StevenK: what bug are you doing ? | 04:10 |
| StevenK | lifeless: bug 884217 | 04:12 |
| wallyworld_ | lifeless: so it seems there's a much larger issue at play here and when that is addressed, the bug i worked on will disappear | 04:12 |
| lifeless | that larger issue is AIUI, in scope | 04:12 |
| wallyworld_ | huwshimi: wgrant: the 2nd mockup is better but i'm concerned about how it will scale for users with more than 1 or 2 policies/roles | 04:13 |
| lifeless | StevenK: I've commented | 04:13 |
| StevenK | I can't see Subteam of when I'm not logged in :-( | 04:14 |
| wgrant | wallyworld_: Indeed. | 04:14 |
| lifeless | StevenK: wallyworld_: so yes, there is a different picture here. | 04:14 |
| lifeless | StevenK: wallyworld_: if curtis wants you to mask this then come back and change it, fine, but I would be very surprised by that. | 04:14 |
| wallyworld_ | lifeless: yes, it does appear in scope. but i'll need to talk to curtis before we charge off to do anythong | 04:14 |
| wallyworld_ | lifeless: i was wondering if those bugs were raised as a stop gap | 04:15 |
| StevenK | Right, then I can't work on this either | 04:15 |
| wallyworld_ | since they are recent | 04:15 |
| wallyworld_ | and the original scope was done a while ago | 04:15 |
| wallyworld_ | huwshimi: wgrant: perhaps we should show the most permissive policy/role and have an ellipses to trigger a popup to see the rest? | 04:16 |
| wgrant | ~wallyworld_, huwshimi: What if each policy is a column (possibly with the name rotated to vertical, if people end up having insane numbers)? | 04:16 |
| wgrant | Possibly. | 04:16 |
| wgrant | I guess people can filter if they want to see the more restricted policies. | 04:16 |
| wallyworld_ | yes | 04:17 |
| wallyworld_ | better to show worse case in the default view | 04:17 |
| wgrant | Well. | 04:17 |
| wgrant | That's the thing. | 04:17 |
| wgrant | It's not necessarily the worst case. | 04:17 |
| wallyworld_ | but how to quantify that | 04:17 |
| wgrant | Exactly. | 04:17 |
| wgrant | For Ubuntu, the worst case is any permission on Security. | 04:17 |
| james_w | poolie, I am | 04:18 |
| huwshimi | wallyworld_ wgrant: How would the Driver, Owner etc. fit into those columns? | 04:18 |
| wallyworld_ | that the trouble with thinking out loud in a public forum | 04:18 |
| wgrant | huwshimi: Ideally they don't. | 04:18 |
| wgrant | huwshimi: Those roles aren't special. | 04:18 |
| james_w | poolie, the synchronized update is a shame | 04:18 |
| wgrant | huwshimi: Although in the default config they will give observer permissions. | 04:18 |
| StevenK | lifeless: I was also looking at bug 618399, your analysis is out of date. | 04:18 |
| wallyworld_ | wgrant: huwshimi: the original mockups implied those roles were special | 04:18 |
| poolie | james_w i guess i could make it look at the version number? | 04:18 |
| poolie | or... | 04:18 |
| StevenK | Where has mup gone? | 04:18 |
| wgrant | wallyworld_: The original mockups are wrong :) | 04:18 |
| poolie | maybe something else | 04:19 |
| lifeless | StevenK: oh, the analysis of bug 618399 ? | 04:19 |
| poolie | i don't have a good sense whether upgrading two packages is especially dangerous | 04:19 |
| wgrant | huwshimi, wallyworld_: So, when I create a new project, the security contact will get an observer permission on the Security policy. But that can be changed. | 04:19 |
| lifeless | StevenK: I had friction there ;) | 04:19 |
| StevenK | lifeless: You did? | 04:19 |
| wallyworld_ | wgrant: huwshimi: yes, just what i was going to type | 04:19 |
| lifeless | StevenK: I thought you were saying the private team analysis was out of date :) | 04:19 |
| StevenK | lifeless: No, which I mentioned a different bug number. | 04:20 |
| huwshimi | wallyworld_ wgrant: so are they just treated like everyone else now? Do they need to be noted e.g. observer (Owner) | 04:20 |
| wallyworld_ | huwshimi: wgrant: and there's the display mode which shows implicit access via team membership, eg if someone is in the bug supervisor team | 04:20 |
| wgrant | huwshimi: We could add that note if we want, but I don't think it's really critical. | 04:20 |
| StevenK | lifeless: I strongly suspect there are a bunch of repeated queries, but the code you implicated in the bug has moved/been deleted. | 04:20 |
| wgrant | wallyworld_: lifeless argues that that is silly. | 04:21 |
| wgrant | wallyworld_: Because eg. most projects will have ~canonical, and that is huge. | 04:21 |
| wgrant | wallyworld_: But I think it should still be done. | 04:21 |
| wallyworld_ | wgrant: i don't think it's silly | 04:21 |
| wallyworld_ | because you can see *why* someone has access | 04:21 |
| wallyworld_ | and correct it if needed | 04:21 |
| huwshimi | wallyworld_ wgrant: So move to private/security columns then? | 04:21 |
| lifeless | mmmm, I argue that a per-person collection for all of ~canonical does not meet user needs. | 04:21 |
| lifeless | they need searches | 04:22 |
| wgrant | It certainly needs a search. | 04:22 |
| lifeless | e.g. 'show me folk with permission not in ~canonical' | 04:22 |
| lifeless | -vastly- more useful. | 04:22 |
| wallyworld_ | lifeless: yes, but what about the case where a project owner says "tell me why fred can see my shit" | 04:23 |
| wallyworld_ | and you can say "that's because he is in team xxx" | 04:23 |
| wallyworld_ | "and team xxx has private/observer permission" | 04:23 |
| lifeless | wallyworld_: thats useful too | 04:23 |
| lifeless | wallyworld_: imagine finding fred by clicking next 15 times. | 04:24 |
| lifeless | wallyworld_: and xxx likewise. | 04:24 |
| lifeless | wallyworld_: *that* isn't useful. | 04:24 |
| * StevenK notes lifeless has gotten distracted. | 04:24 | |
| lifeless | expanding out teams in the default view will *devalue* the view. | 04:24 |
| wallyworld_ | lifeless: no, but you search for fred and he comes up in the results and you can instantly see his indirect access | 04:24 |
| lifeless | wallyworld_: sure, and I think thats desirable. | 04:25 |
| wgrant | lifeless: In the default view, yets. | 04:25 |
| wgrant | yes. | 04:25 |
| wgrant | It certainly needs to default to showing only explicit grants. | 04:25 |
| wallyworld_ | lifeless: so i think we agree, we're just discussing different valid use cases, both of which will be supported | 04:25 |
| lifeless | I think a displaymode that shows *everything* expanding teams isn't useful | 04:25 |
| wallyworld_ | lifeless: we don't have that | 04:26 |
| lifeless | I have had the impression that that is currently intended. | 04:26 |
| lifeless | from statements like '17:20 < wallyworld_> huwshimi: wgrant: and there's the display mode which shows implicit access via team membership, eg if someone is in the bug supervisor team | 04:26 |
| wallyworld_ | we have a list matching the search criteria which can optinally show if access is indirect or not and how | 04:26 |
| wgrant | That has to show implicit access via team membership.; | 04:26 |
| wallyworld_ | lifeless: ^^^^ | 04:26 |
| wgrant | It's unlikely it will ever be used in an unfiltered form, however. | 04:27 |
| lifeless | Perhaps I'm being odd about this | 04:27 |
| lifeless | I'm sure you have a good understanding; I'm probably misunderstanding due to language things | 04:27 |
| wallyworld_ | lifeless: take my 2 statements above together and the other stuff i've just said that you agreed with. that's the intent of it, not an expanded team view | 04:27 |
| lifeless | I just want to save you from implementing a very slow thing because you're bringing back hundreds of times the needed data within the DB | 04:28 |
| poolie | james_w, oh, the other option would be to turn that option on by default for dailydeb | 04:28 |
| wallyworld_ | huwshimi: wgrant: the private/security columns question | 04:28 |
| wallyworld_ | not sure that will work well for everything | 04:29 |
| wgrant | wallyworld_: Oh? | 04:29 |
| james_w | poolie, yeah, I'm not sure if that's a good idea | 04:29 |
| wallyworld_ | perhaps it will. i guess those two categorisations are the only ones we will have | 04:30 |
| james_w | poolie, I'd forgotten that this was both in packages | 04:30 |
| poolie | builder and buildd? | 04:30 |
| poolie | also they're hard to type together | 04:30 |
| james_w | so upgrade should be fine | 04:30 |
| james_w | heh, yeah | 04:30 |
| lifeless | StevenK: still 80 spph lookups | 04:34 |
| lifeless | StevenK: if you can repro locally, LP_SQL_DEBUG_EXTRA=1 should give you the code paths | 04:35 |
| poolie | http://lpqateam.canonical.com/qa-reports/deployment-stable.html often seems to get confused about qa-ok vs untestable | 04:35 |
| poolie | eg bug 884092 | 04:35 |
| wgrant | poolie: eg.? | 04:35 |
| poolie | i guess it doesn't matter as long as it knows they're not blocking deployment | 04:35 |
| StevenK | lifeless: Sure -- what I'm saying is I couldn't figure out which code path is implicated. | 04:35 |
| huwshimi | wgrant wallyworld_: So with the columns approach it could be something more like this: http://people.canonical.com/~huwshimi/policy3.png | 04:35 |
| poolie | 884092 is called 'ok' on the report but is untestable on the bug, and always has been | 04:35 |
| wgrant | poolie: Ah, qa-untestable counts as qa-ok. | 04:36 |
| poolie | but some others are called untestable? | 04:36 |
| huwshimi | wgrant wallyworld_: But wallyworld_ might be right about it not scaling very well (if/when there are custom policies) | 04:36 |
| wgrant | poolie: 'untestable' on that report means that there's no bug, or it's marked as [no-qa] | 04:36 |
| poolie | oh, no-qa is called untestable | 04:36 |
| poolie | ok | 04:36 |
| StevenK | By rights, qa-untestable should be untestable too | 04:36 |
| wgrant | StevenK: Yes. | 04:36 |
| wallyworld_ | huwshimi: wgrant: i think that look ok, but we want the edit icons next to each permission to trigger insitu popup editing | 04:36 |
| StevenK | But the deployment report is ... crap | 04:36 |
| wgrant | But lots of things should be different :P) | 04:36 |
| poolie | not a big deal | 04:37 |
| huwshimi | wallyworld_: To edit security/private individually? | 04:37 |
| wgrant | wallyworld_, huwshimi It would be more scannable if the columns weren't so wide and text. | 04:37 |
| wallyworld_ | huwshimi: yes, on the current interactive demo, you can change the permission from observer -> restricted etc by clicking the cell | 04:38 |
| wallyworld_ | ie the edit icon in the cell | 04:38 |
| wallyworld_ | like for bug importance etc | 04:38 |
| StevenK | lifeless: Did you determine the 80 SPPH lookups locally or from an OOPS? | 04:39 |
| huwshimi | wgrant, wallyworld: So, sticking with the columns like this then (with a few improvements)? | 04:39 |
| lifeless | https://lp-oops.canonical.com/oops.py/?oopsid=2102F9#repeatedstatements | 04:39 |
| wallyworld_ | huwshimi: wgrant: i think for the next iteration that;s ok. get user feedback etc | 04:40 |
| wgrant | wallyworld_, huwshimi: Yeah, looks reasonable. | 04:40 |
| wgrant | I think it may be better to use less text, but I guess we'll see. | 04:40 |
| huwshimi | wgrant: What do you mean by less text? | 04:41 |
| wallyworld_ | it's hard to think of what "less" text to use | 04:41 |
| wgrant | huwshimi: Well, "Restricted observer" and "Observer" are pretty huge ways to represent a tri-state field. | 04:41 |
| wgrant | Makes the table very unscannable. | 04:42 |
| huwshimi | wgrant: Ah I seee | 04:42 |
| wallyworld_ | huwshimi: so when you talk to matthew, you can let him know the interactive demo has been tweak as per the initial feedback and we are looking to move forward also with the stuff discussed today | 04:42 |
| wallyworld_ | huwshimi: wgrant: we could use abbreviations like O and R and have popup help bubble? | 04:43 |
| wgrant | wallyworld_: That was along the lines of what I was thinking. That would also allow us to fit in an awful lot of columns, but hopefully nobody will ever want to do that. | 04:44 |
| wgrant | But you never know with OEM :) | 04:44 |
| wallyworld_ | wgrant: abbreviations are difficult because you need to discover what they mean, but seems like we do need it here | 04:45 |
| wallyworld_ | anyways, huwshimi can ask the users what they want :-) | 04:46 |
| wgrant | These would pretty clearly make the page more readable, and the existing terms need description anyway. | 04:46 |
| wallyworld_ | yep | 04:46 |
| wgrant | So, something to consider. | 04:47 |
| huwshimi | wallyworld_: Well I think Matthew will be talking to people (I'm not at UDS) | 04:47 |
| wallyworld_ | oh, i thought you were for some reason | 04:47 |
| wgrant | lifeless: Any objections to removing the old non-CTE visibility code? | 04:49 |
| wgrant | lifeless: Doesn't seem to have caused any new timeouts. | 04:49 |
| poolie | fruit salad! http://people.canonical.com/~jelmer/recipe-status/bzr.html | 04:49 |
| wgrant | poolie: I hate to think how long that took to generate. | 04:50 |
| poolie | or how many sql queries, when it should be about 1 | 04:50 |
| lifeless | wgrant: we may be able to revert back to it and it is a bit simpler (there was talk about a regression in 8.4.9) | 04:50 |
| poolie | lifeless: if you're orc and not flat out could you read | 04:53 |
| poolie | https://code.launchpad.net/~mbp/testscenarios/module-scenarios/+merge/80287 | 04:53 |
| poolie | https://code.launchpad.net/~mbp/launchpad/678090-affected-count/+merge/81108 | 04:53 |
| poolie | neither is very big | 04:53 |
| wgrant | lifeless: Well, it's all going to die soonish anyway. | 04:54 |
| poolie | <lifeless> poolie: this requires creating two small projects - one to hold the current common code, and one to hold the buildd production code. | 05:01 |
| poolie | do you have any opinion about what they should be called? | 05:01 |
| poolie | lp-buildd and ...? | 05:01 |
| lifeless | I haven't thought about it | 05:01 |
| lifeless | but https://dev.launchpad.net/CreatingNewProjects | 05:01 |
| lifeless | is our guidelines | 05:01 |
| wgrant | Well. | 05:02 |
| wgrant | Or you can just work out how to remove lp-buildd's dep on readyservice. | 05:02 |
| wgrant | That's all it needs from LP nowadays, IIRC. | 05:02 |
| lifeless | yes | 05:02 |
| lifeless | thats used for the LP test suite | 05:02 |
| lifeless | to detect when the test slave is ready to use | 05:02 |
| wgrant | It can't just try to connect? | 05:03 |
| lifeless | perhaps | 05:03 |
| lifeless | I have no opinion | 05:03 |
| poolie | https://bugs.launchpad.net/launchpad/+bug/800295 | 05:04 |
| poolie | bot is on leave today? | 05:05 |
| nigelb | Its been like this since yesterday | 05:07 |
| nigelb | (morning btw) | 05:07 |
| poolie | hi nigelb | 05:28 |
| nigelb | Hey poolie! | 05:28 |
| nigelb | I realized UDS is hard even when remotely partcipating :) | 05:29 |
| poolie | :) | 05:29 |
| poolie | maybe i'll see you at the next one | 05:37 |
| nigelb | Hopefully | 05:38 |
| nigelb | :) | 05:38 |
| poolie | wgrant: just trying to connect sounds good to me | 05:38 |
| poolie | it does seem to be barely used | 05:39 |
| huwshimi | wallyworld_ wgrant: Does this look roughly ok now? http://people.canonical.com/~huwshimi/policy4.png | 06:19 |
| wgrant | huwshimi: Hm, maybe the role could go in a separate column? | 06:19 |
| wgrant | Since it's presently duplicated between the two, and bears no particular relevance to either one. | 06:20 |
| wgrant | or it could just be parenthesised in the Person column. | 06:20 |
| huwshimi | wgrant: Yeah I was going to suggest the latter | 06:20 |
| wgrant | That looks reasonable. I hope we can do better than that with the search UI, but it otherwise looks good. | 06:21 |
| huwshimi | wgrant: There's certainly room to improve, but Matthew just needs something by tonight | 06:21 |
| wgrant | The edit icons should probably only be shown on hover... or there is an old more subtle variant that we could use. | 06:21 |
| wgrant | Otherwise it's going to look *really* cluttered. | 06:21 |
| wgrant | Right. | 06:22 |
| wgrant | stub: Hi. Will you able to review https://code.launchpad.net/~wgrant/launchpad/observer-db/+merge/81104 todayish? | 06:25 |
| stub | yer, already had a quick look | 06:25 |
| wallyworld_ | huwshimi: looks good | 06:26 |
| wallyworld_ | huwshimi: but i think we are missing the edit icons in a table column which take the user to the person/team listing page | 06:26 |
| wallyworld_ | huwshimi: like i did in the latest mockups | 06:27 |
| stub | wgrant: How will the policies be created? | 06:27 |
| stub | wgrant: As in the AccessPolicy records? | 06:27 |
| wgrant | stub: Initially by model code on project creation, and a garbo job. | 06:27 |
| huwshimi | wallyworld_: Oh, do you have a link? | 06:27 |
| huwshimi | wallyworld_: Or are these the mockups you did ages ago? | 06:27 |
| wgrant | stub: Once we're done with the migration, project owners will be able to create them themselves. | 06:27 |
| wgrant | stub: (for example, Ubuntu has two additional polices to allow apport to work properly) | 06:28 |
| wallyworld_ | huwshimi: http://people.canonical.com/~ianb/disclosure/manage_disclosure_index.html | 06:28 |
| huwshimi | wallyworld_: Ah thanks | 06:28 |
| stub | Why did you go with a text field display_name rather than an enum? | 06:28 |
| wallyworld_ | huwshimi: same url as before, but i updated based on feedback from dan | 06:28 |
| wallyworld_ | huwshimi: i did a cc all on the email i sent but you must not have been on the list. i'll forward now | 06:28 |
| wgrant | stub: Some projects need customisation, and it's not clear that an enum gives us significant value. | 06:28 |
| wallyworld_ | huwshimi: did you get dan's original email? | 06:29 |
| huwshimi | wallyworld_: No I did not | 06:29 |
| wallyworld_ | i'll send that too then | 06:29 |
| stub | wgrant: The theory is that enums involve less storage space and pick up typos at lint time. | 06:29 |
| huwshimi | wallyworld_: This mockup seems to have some old stuff in it too (than the last mockups I sent) | 06:29 |
| lifeless | stub: wgrant is adding a name column too FWIW. enum may be better - I have no fixed opinion | 06:30 |
| wgrant | The column should be in the diff now. | 06:30 |
| wgrant | name column, that is. | 06:30 |
| stub | wgrant: Will every display_name have corresponding code changes in lp? And is it possible for a (product, display_name) policy for two different policies to act differently? | 06:30 |
| wallyworld_ | huwshimi: i only updated based on dan's feedback. which ones did you send? | 06:30 |
| wgrant | stub: No, there will be no code changes for new policies. | 06:30 |
| stub | I see no name field | 06:31 |
| lifeless | welll | 06:31 |
| * wgrant rechecks. | 06:31 | |
| lifeless | there may be business rules about who gets which policies | 06:31 |
| wgrant | Well, it's probably a boolean of the form "you are allowed to create new policies" | 06:31 |
| wgrant | Because you are Canonical or have paid us. | 06:32 |
| wgrant | stub: Hm, what diff are you looking at? | 06:32 |
| wgrant | I pushed the new column more than two hours ago, and requested your review afterwards. | 06:32 |
| stub | I mean that if I create a record ('ubuntu', 'Lord of All') would there need to be code change to make that do something useful, or are people accessing this stuff via the apis or something external to Launchpad? | 06:32 |
| wgrant | So even the email should have it. | 06:32 |
| stub | https://code.launchpad.net/~wgrant/launchpad/observer-db/+merge/81102 | 06:32 |
| stub | oic. old mp | 06:32 |
| wgrant | Yeah, 81104 is new. | 06:33 |
| wgrant | 81102 should be dead... | 06:33 |
| wgrant | (I merged devel, but didn't set it as a prereq the first time) | 06:33 |
| wgrant | stub: It'll still do useful stuff. Eventually we'll have UI to choose a policy, and there will shortly be UI to customise who can access a policy. | 06:33 |
| wgrant | The initial pass will retain the private/security flags in the UI, mapping them onto two well-known policy names. | 06:34 |
| stub | Yes, I'm just trying to see if there is any point having this data in the database or if it should be hard coded in an enum (dropping name & display_name from the schema) | 06:34 |
| wgrant | That will later be replaced/extended with a way to select an arbitrary policy. | 06:34 |
| wgrant | For example, Ubuntu needs 'apport unprocessed' and 'apport processed' or similar policies. | 06:34 |
| lifeless | well maybe | 06:35 |
| lifeless | apport can just move off of lp entirely | 06:35 |
| wgrant | In 5 years. | 06:35 |
| lifeless | nah | 06:35 |
| lifeless | no need to wait that long | 06:35 |
| wgrant | It's been on LP for a bit over 5 years so far :) | 06:36 |
| wgrant | Another 5 wouldn't surprise me. | 06:36 |
| stub | At this point I can't see any reason to have two text columns and 4 indexes over one integer column and two indexes. I can see some disadvantages. | 06:38 |
| wgrant | We'll need to talk to stakeholders about restricting them to a single set of artifacts. | 06:40 |
| wgrant | But I guess it might work. | 06:40 |
| stub | What is the restriction here? | 06:40 |
| huwshimi | wallyworld_: The last mockups I sent were ages and ages ago | 06:40 |
| wgrant | stub: I'm not adding an OEM Engineers value to an enum. | 06:40 |
| poolie | https://code.launchpad.net/~mbp/launchpad/800295-buildd-split/+merge/81111 | 06:41 |
| poolie | probably prepares to split them | 06:41 |
| wgrant | stub: If we restrict everything to an enum, when someone comes up with a new reason to split out some of their artifacts, they need a code change, and we need project-specific code in LP. | 06:41 |
| stub | wgrant: How does this work with the proposed model? | 06:42 |
| wgrant | stub: They click the "New access policy" link. | 06:42 |
| lifeless | there is some undesigned stuff here | 06:42 |
| wgrant | They enter details, then wander over to the relevant artifacts and click "Change access policy" | 06:42 |
| stub | Right, and they select from an existing list or do they type in some names? | 06:42 |
| lifeless | particularly around tightly coupled bugs (cross pillar) | 06:42 |
| wgrant | Type in some names. | 06:42 |
| wallyworld_ | huwshimi: sorry i didn't use them this time. hopefully the latest work you've done plus the next round of testing will see us ready to start the proper coding work. i'd be interested in your thoughts on the emails i just sent too at some stage | 06:43 |
| lifeless | and for now, we're forcing a specific set of policies | 06:43 |
| wgrant | For the initial migration, yes. | 06:43 |
| stub | ok. And then is there some science fiction to map this policy to a set of permissions? | 06:43 |
| stub | through the web or via apis or something? Or does that require code changes? | 06:43 |
| wgrant | Web UI. | 06:43 |
| wgrant | Through the usual disclosure management web UI. | 06:43 |
| stub | ok. So the current model makes sense to support that. | 06:44 |
| wgrant | http://people.canonical.com/~huwshimi/policy4.png are the latest mockups. | 06:44 |
| wgrant | Well, a subset of them. | 06:44 |
| stub | How many rows do we expect in AccessPolicy btw? Wondering if the indexes should be partial or not. | 06:44 |
| lifeless | wgrant: I thought that hadn't been decided on | 06:44 |
| wgrant | lifeless: What hadn't? | 06:44 |
| lifeless | wgrant: that we were implementing a saner way of doing what we do today, future proofing *future* design decisions | 06:45 |
| huwshimi | wallyworld_: Sure, I need to EOD but I'll take a look tomorrow. I think I'll need to do a bit of a review of the UI after UDS is over and we have the feedback so I can make sure things are not being overlooked | 06:45 |
| huwshimi | wgrant: Actually http://people.canonical.com/~huwshimi/policy5.png has the last change (moving the role) | 06:45 |
| wgrant | lifeless: Well, we need at least two custom access policies, and I believe OEM will want more. | 06:45 |
| lifeless | what two ? | 06:45 |
| wgrant | lifeless: apport | 06:45 |
| wgrant | And no, we're not moving apport off LP next week. | 06:45 |
| lifeless | we don't | 06:45 |
| wallyworld_ | huwshimi: np. i didn't expect anything else today :-) | 06:45 |
| wgrant | stub: Just over two per pillar, I suspect. | 06:46 |
| wgrant | stub: They probably should be partial, yes. | 06:46 |
| lifeless | wgrant: are you saying we *need* it because apport bugs are currently using the limited-subscriber-list hack ? | 06:46 |
| stub | wgrant: Should AccessPolicyGrant.artifact be declared NOT NULL? | 06:46 |
| wgrant | stub: No. | 06:46 |
| wgrant | stub: There are policy-wide grants. | 06:46 |
| wgrant | stub: Which are implemented by leaving artifact null. | 06:46 |
| wgrant | lifeless: Yes. | 06:47 |
| stub | wgrant: We will need to fix that UNIQUE then as it doesn't do what you think it does | 06:47 |
| wgrant | stub: I have a second partial one afterwards. | 06:47 |
| lifeless | wgrant: so, one crashdump policy should supply that | 06:47 |
| wgrant | lifeless: WIth a few hundred thousand restricted observers. | 06:47 |
| stub | wgrant: I think we need two partials here. | 06:47 |
| wgrant | Sure. | 06:47 |
| lifeless | wgrant: !cite | 06:47 |
| wgrant | stub: UNIQUE (policy, person, artifact) should work where artifact is not null, right? | 06:48 |
| wgrant | lifeless: Once apport has processed a bug and removed the core dump, it subscribes a restricted Ubuntu team. | 06:48 |
| lifeless | wgrant: oh, for a second pass review? I thought it made them public straight away | 06:48 |
| wgrant | stub: Then I have a UNIQUE (policy, person) WHERE artifact IS NULL afterwards. | 06:48 |
| wgrant | lifeless: If they're dupes I think they get all the attachments obliterated, and then made public. | 06:49 |
| stub | wgrant: I think what you have works, but the index has unnecessary rows (all the NULL artifact rows, and any queries with NULL artifact would be using the partial index) | 06:49 |
| wgrant | lifeless: But normally they get the coredump removed, retraces attached, and ~crash-triagers-universe or similar subscribed. | 06:49 |
| lifeless | we could do two tables | 06:49 |
| lifeless | one full one restricted | 06:49 |
| wgrant | stub: True. | 06:49 |
| wgrant | Could. | 06:50 |
| wgrant | But now I can just say AccessPolicyGrant.artifact IS NULL or AccessPolicyGrant.artifact = blah :) | 06:50 |
| lifeless | OTOH preventing nuts data is easier with one table | 06:50 |
| stub | wgrant: Can we swap the order of those indexes around, putting the person column first to keep people merge happiest? | 06:51 |
| lifeless | e.g. if we want to say you can't be restricted *and* full | 06:51 |
| stub | wgrant: if we are doing queries like that, fine. | 06:51 |
| lifeless | wgrant: I don't think support apport is equivalent to supporting arbitrary custom policies | 06:52 |
| wgrant | stub: That's the main query. Checking whether someone has access to the whole policy, or this particular artifact. | 06:52 |
| lifeless | wgrant: I think its fixing 5 year old tech debt where apport used a poor mechanism to its advantage | 06:52 |
| wgrant | stub: Ah, I did have a second index with person first, but dropped it somewhere along the line. | 06:52 |
| wgrant | stub: Need policy first for some things, so I'll readd a second one. | 06:52 |
| lifeless | wgrant: so we start with 4 policies, not 2 | 06:52 |
| stub | wgrant: yes, add a separate index for person then. | 06:52 |
| lifeless | wgrant: that doesn't imply arbitrary custom policies, nor the UI to support that. | 06:53 |
| wgrant | lifeless: Will need to check with stakeholders, particularly OEM, but perhaps. | 06:53 |
| lifeless | wgrant: we haven't offered custom rules to OEM AFAIK | 06:53 |
| lifeless | wgrant: but sure | 06:54 |
| wgrant | lifeless: Yes, and we've already fucked them over once. | 06:54 |
| lifeless | wgrant: you're referring to the bug pillar constraint? | 06:54 |
| wgrant | Yes, particularly the mass-deletion. | 06:54 |
| lifeless | hasn't been done yet has it ? | 06:54 |
| wgrant | They're not at all clear on what we're doing. | 06:54 |
| wgrant | And what constraints we're putting in place. | 06:54 |
| lifeless | yeah, that has been largely resolved today, though I think you'll scream :) | 06:55 |
| wgrant | But saying we only have two policies, we're restricting what they can do. | 06:55 |
| wgrant | Oh? | 06:55 |
| lifeless | the oem project is really the union of disclosure + bug deps | 06:56 |
| wgrant | They had better not be back in scope. | 06:56 |
| wgrant | That extends the project by months. | 06:56 |
| lifeless | nope | 06:56 |
| lifeless | just ignore them, disclosure doesn't need to be usable by oem until both projects are finished | 06:57 |
| wgrant | Huh? | 06:57 |
| wgrant | You know we're ripping out the old privacy mechanism, right? | 06:57 |
| stub | wgrant: Why do we want the links on bug and branch to AccessPolicy, when the links are already there via AccessPolicyGrant and AccessPolicyArtifact? | 06:58 |
| lifeless | the proposal is to leave them in place while you get all the rest of the work done, for oem under a ff | 06:59 |
| wgrant | lifeless: Fuck. No. | 06:59 |
| lifeless | more or less | 06:59 |
| wgrant | Maybe if we were a sensible bugtracker. | 06:59 |
| wgrant | But we're not. | 06:59 |
| wgrant | All our projects are intertwined. | 06:59 |
| wgrant | stub: That's one of the bits I'm less sure of. Firstly, there isn't an explicit grant for every artifact. I could put the policy on AccessPolicyArtifact, but then we have to join through an extra table for every private bug. | 07:02 |
| stub | Yes, it seems denormalization. Wondering if it is necessary or if it is premature optimization. | 07:03 |
| wgrant | It is a minor denormalisation, yes. | 07:03 |
| stub | Branch and Bug just keep growing wider :-( | 07:04 |
| wgrant | lifeless: Is this being seriously considered? | 07:04 |
| wgrant | lifeless: It's probably faster to do bug dependencies. | 07:04 |
| lifeless | wgrant: yes, seriously. | 07:06 |
| lifeless | wgrant: I can talk on voice if you want, in ~15 minutes. | 07:06 |
| wgrant | That's bordering on entirely ridiculous. | 07:06 |
| wgrant | It would probably even be worth reducing ourselves to a single maintenance squad for a few weeks to get bug dependencies done early, rather than working on optimising all the hybrid queries and maintaining two UIs and models for years. | 07:09 |
| wgrant | There'd be a lot of criticals from that. | 07:09 |
| lifeless | not talking yeats | 07:09 |
| lifeless | months at most | 07:09 |
| wgrant | lolololol | 07:09 |
| lifeless | bug deps are 2nd in queue | 07:09 |
| lifeless | listings, testing, deps | 07:09 |
| wgrant | Yes. | 07:10 |
| lifeless | once deps are done, they get migrated, and disclosure can finish off at its leisure | 07:10 |
| wgrant | Jump the queue, do deps after listings in parallel with disclosure. | 07:10 |
| wgrant | Problem solved. | 07:10 |
| lifeless | deps will be parallel with disclosure | 07:10 |
| wgrant | But when? | 07:13 |
| wgrant | We may be better off suspending the visibility work until it's done, if the alternative is to keep both around in parallel. | 07:14 |
| lifeless | tell me something | 07:15 |
| lifeless | if you migrate them to have rows in each project | 07:15 |
| lifeless | and a flag saying this is ok for projects x y z | 07:15 |
| lifeless | does that add significant overhead? | 07:15 |
| lifeless | my understanding of the data model is that it doesn't | 07:15 |
| lifeless | after all, we were going to do that originally but it was the ownership ramifications that were intractable | 07:16 |
| wgrant | What does that mean? | 07:16 |
| wgrant | Who has access? | 07:16 |
| stub | What is the point of a bug/branch linked to an access policy without a access policy grant? Are there implicit grants? | 07:16 |
| lifeless | union of | 07:16 |
| wgrant | stub: Most grants are policy-wide. | 07:16 |
| wgrant | stub: So they apply to all artifacts within the policy. | 07:17 |
| wgrant | lifeless: That means the disclosure management views are a lie. | 07:17 |
| lifeless | wgrant: yes, acceptable until all the pieces come together | 07:17 |
| lifeless | wgrant: *for those projects* | 07:17 |
| lifeless | wgrant: heck, it could oops for them, and it wouldm't matter - what they need involves disclosure + deps; until both are done they aren't able to use it anyhow | 07:18 |
| wgrant | lifeless: So, this completely changes the model, because we now need multiple policies per bug. Or we need to entirely preserve the old mechanism, and reoptimise every query to be a hybrid and hope it's actually possible to make it performant. | 07:19 |
| stub | Bah. I'm loath to extend bug and branch any more, but given the column is going to be used by pretty much all queries for visibility. Do we get to drop Bug/Branch.private with this? | 07:19 |
| lifeless | stub: yes | 07:19 |
| wgrant | stub: Yes, that will be dropped with legacy disclosure's destruction. | 07:19 |
| wgrant | stub: Bug.security_related too, in all probability. | 07:19 |
| wgrant | And Branch.transitively_private. | 07:19 |
| lifeless | wgrant: I'm not sure transitively goes | 07:20 |
| lifeless | wgrant: unless we don't permit private & ppublic branches in the same project ever | 07:20 |
| stub | So I can understand the current model and am fine with it. I think we can make a lot of the indexes partial for a speed win in AccessPolicy & AccessPolicyArtifact | 07:21 |
| wgrant | lifeless: We've not quite worked out how stacking works. | 07:21 |
| stub | I suspect transitively_private will no longer make sense when the private flag goes. It is just a cache really. | 07:21 |
| lifeless | wgrant: yes | 07:22 |
| wgrant | As a flag it certainly will no longer make sense. | 07:22 |
| lifeless | its a derived value though | 07:22 |
| wgrant | It is, but saying that something is "just private" will no longer be possible. | 07:22 |
| wgrant | There needs to be a policy. | 07:23 |
| wgrant | I don't know what restrictions we'll have around stacking. | 07:23 |
| wgrant | stub: Indeed, I should make lots of those partial. | 07:23 |
| stub | Will Branch/Bug.access_policy become NOT NULL? | 07:24 |
| wgrant | stub: I expect the schema to make privacy queries substantially faster, as it won't have to indirect through a linking table for most things. | 07:24 |
| wgrant | stub: No -- NULL means public. | 07:24 |
| stub | How does that work for hidden or private products? (do we have them?) | 07:25 |
| wgrant | A reasonable point. | 07:25 |
| wgrant | Hmm. I hate to think how that would perform. | 07:26 |
| wgrant | Because that would require bug searches to look up policies for even public bugs... | 07:27 |
| stub | Probably about the same as LEFT OUTER JOIN with the AccessPolicy or a UNION like we do with private stuff atm. | 07:27 |
| stub | Anyway, it might end up nicer and/or faster if it becomes NOT NULL and public bugs are linked to a public AccessPolicy | 07:29 |
| lifeless | we already check project.active | 07:29 |
| wgrant | Hmm, so we do. | 07:29 |
| wgrant | So maybe that would work. | 07:30 |
| lifeless | if we want to denorm inactivity, we can do that by (for instance) creating a non-public policy for them | 07:30 |
| lifeless | stub: a hidden or private product will have no public bugs | 07:30 |
| lifeless | stub: by definition | 07:30 |
| lifeless | stub: we don't [really] have them yet, but we will. Also private distros. | 07:31 |
| stub | lifeless: Well, if a product could override what 'public' means you could have hidden bugtasks on a bug. But I'm not sure people want to go down that path. | 07:31 |
| stub | But even without, the queries just might come out nicer so worth keeping in mind when hacking the code. | 07:32 |
| stub | wgrant: Do you want to make the partial index changes and push? | 07:33 |
| wgrant | stub: Do I also want to make AccessPolicyArtifact's indices partial? | 07:36 |
| lifeless | wgrant: ok, do you want a voice chat about oem? | 07:40 |
| stub | wgrant: Yes, I think so | 07:41 |
| wgrant | lifeless: Sure. | 07:41 |
| wgrant | I'm Skyped up. | 07:41 |
| lifeless | try calling me | 07:42 |
| lifeless | I think skype is running, can't tell(unity) | 07:42 |
| lifeless | wgrant: ^ | 07:43 |
| wgrant | Calling | 07:43 |
| * StevenK attempts to fix the qa-tagger | 08:18 | |
| StevenK | Two rollbacks, which I think overlap? Seriously? :-( | 08:19 |
| wgrant | StevenK: That works normally. | 08:19 |
| wgrant | What's the error? | 08:19 |
| StevenK | It isn't crashing, but r14216 is marked as needstesting, I set it back to qa-bad bad-commit-14216 | 08:20 |
| StevenK | Revision 14216 can be deployed if 14223 is deployable: rolledback | 08:21 |
| StevenK | There we go | 08:21 |
| * StevenK fixes r14219 too | 08:22 | |
| wgrant | (for the record, my earlier objections to lifeless' crazy plan are rescinded now that he's clarified he doesn't actually suggest that we keep legacy disclosure around, just that we temporarily weaken new disclosure for some projects) | 08:27 |
| StevenK | wgrant: Bleh. | 08:31 |
| StevenK | wgrant: Now both bad commits are so marked, but r14229 is linked to the same bug. | 08:33 |
| wgrant | StevenK: Mark that bug qa-ok or qa-untestable as appropriate. | 08:33 |
| wgrant | The bad-commit-XXX will still taint the bad rev. | 08:33 |
| StevenK | It was marked as needstesting 10 hours ago, I guess abentley has not done QA on it yet. | 08:34 |
| wgrant | Leave it needstesting, then. | 08:34 |
| StevenK | And I think deryck has done the same thing. | 08:34 |
| * StevenK digs. | 08:34 | |
| * StevenK gives up on deploying before Monday. | 08:36 | |
| === rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: lifeless, rvba | Critical bugtasks: 266 | ||
| StevenK | Right, two revisions need QA to get us to a deployable state. | 08:42 |
| StevenK | rvba with r14225, and abentley with r14229 | 08:42 |
| StevenK | Well, deployable until r14231 at least. | 08:43 |
| rvba | StevenK: r14225 is actually qa-ok (it's behind a ff anyway) but I forgot to mark it incr when I landed it… | 08:44 |
| rvba | so I marked it qa-ok first, and the I removed the qa tag altogether maybe I got the qa tagger confused, sorry about that. | 08:45 |
| rvba | s/and the/and then/ | 08:46 |
| rvba | StevenK: should I re-add the qa-ok tag? | 08:47 |
| StevenK | rvba: If you remove the tag altogether the qa tagger will assume it's not ok -- please add the tag if it is. | 08:49 |
| rvba | StevenK: done. | 08:49 |
| adeuring | good morning | 08:59 |
| poolie | hi | 09:00 |
| lifeless | allenap: so what was the rabbit/txlongpoll qa issue? | 09:15 |
| lifeless | stub: fdt - how would you feel about us removing the long xact check | 09:19 |
| lifeless | stub: (for readonly conns) | 09:19 |
| lifeless | stub: or can we not tell.. | 09:19 |
| stub | lifeless: A readonly connection will still block the updates | 09:22 |
| lifeless | stub: yes, thus killing it | 09:22 |
| bigjools | lifeless: re. txlongpoll - it just started worked so we figured it was something you did to Rabbit | 09:22 |
| bigjools | working* | 09:22 |
| lifeless | ok great | 09:23 |
| bigjools | need to get it in production now | 09:23 |
| lifeless | i didn't see an update to the ticket about prod rabbit | 09:23 |
| bigjools | but we need a deployment strategy | 09:23 |
| lifeless | which IIRC was blocked pending txlongpoll on staging being happyt | 09:23 |
| lifeless | bigjools: related question | 09:23 |
| stub | lifeless: I mean if we let them stay, they will block the updates. ALTER TABLE and most DDL needs an ACCESS EXCLUSIVE lock, which conflicts with the ACCESS SHARE locks taken out by SELECT statements. | 09:23 |
| poolie | bigjools, lifeless: so if we split out the buildds, i'm presuming we want the buildmaster tests to still be able to start it | 09:23 |
| lifeless | stub: yes, I don't mean let them stay | 09:24 |
| lifeless | stub: I mean kill them rather than aborting | 09:24 |
| stub | oic. | 09:24 |
| bigjools | poolie: sorry, I think I am missing context | 09:24 |
| poolie | sorry | 09:24 |
| poolie | i'm looking at https://bugs.launchpad.net/launchpad/+bug/800295 | 09:24 |
| lifeless | bigjools: does txlongpoll have amqp oopses configured ? | 09:24 |
| poolie | but specifically, robert suggested trying to split out the buildd source from launchpad proper | 09:24 |
| stub | We could, but it is a workaround the real problem that something screwy is happening that needs to be investigated. | 09:24 |
| bigjools | lifeless: I believe so | 09:25 |
| lifeless | bigjools: great | 09:25 |
| lifeless | bigjools: I'd like to confirm that; how do I go about it ? | 09:25 |
| bigjools | poolie: so yes I think some of the b-m tests use the buildd | 09:25 |
| stub | lifeless: The theory is that nothing except a few well known system connections should have long running transactions open, and if this is not the case the system might be unstable and we should not proceed without investigation. | 09:25 |
| bigjools | poolie: we just make it a source dependency in versions.cfg etc. | 09:26 |
| lifeless | stub: so far it seems to be generating false positives | 09:26 |
| bigjools | poolie: the buildd code should be a GPL2 project on its own | 09:26 |
| lifeless | stub: things which yes we should fix but they are totally safe to interrupt | 09:26 |
| bigjools | rvba: did txlongpoll get amqp oopses? | 09:26 |
| poolie | right, and it should probably expose a python module that contains a test fixture etc? | 09:27 |
| bigjools | poolie: right | 09:27 |
| bigjools | poolie: in fact I suspect we need 2 projects, the buildd and a buildd-fixture | 09:27 |
| stub | lifeless: Right. So we can either ignore everything and not do the check at all (possibly causing things to explode because something is screwing up) or keep things as they are | 09:27 |
| bigjools | LP just depends on the latter | 09:27 |
| poolie | ? | 09:28 |
| poolie | won't it need the actual buildd, to run it? | 09:28 |
| lifeless | stub: we put out a broad call for things that deal with nontransactional data | 09:28 |
| lifeless | stub: and got back the whitelist | 09:28 |
| bigjools | yes - dependency chain | 09:28 |
| bigjools | it's what we did with txlongpollfixture | 09:28 |
| stub | lifeless: yes. I'm more thinking of things like postgresql processes getting hung in odd states or thrashing trying to calculate multibillion row result sets and that sort of thing. | 09:29 |
| poolie | oh i see, it only directly depends on the fixture, right | 09:29 |
| poolie | though, if we just bring it in as an egg(?) or branch, it doesn't really need to be separately packaged | 09:29 |
| bigjools | the thought of being able to type "make run_buildd" is appealing :) | 09:29 |
| lifeless | stub: so we try a cancel backend; wait 5 seconds; check | 09:29 |
| lifeless | stub: of the slow things first | 09:30 |
| lifeless | ? | 09:30 |
| stub | We also have the option of increasing the timeout. | 09:30 |
| bigjools | poolie: if we want to pull it in on buildout it should be an egg really | 09:30 |
| lifeless | stub: which timeout ? | 09:30 |
| stub | lifeless: We could, yes. That starts causing outages before the real outage. | 09:30 |
| stub | lifeless: The definition of a long running transaction | 09:30 |
| lifeless | stub: of things with -long- transactions | 09:30 |
| bigjools | we don't need to package it I guess | 09:30 |
| lifeless | stub: and long is already defined longer than any webapp, right ? | 09:31 |
| bigjools | but it is already packaged | 09:31 |
| stub | lifeless: Yes. So it shouldn't affect anything interactive that isn't already messed up. | 09:31 |
| poolie | what would be the steps, roughly, to 'make run_buildd'? | 09:31 |
| lifeless | stub: which means we're not really causing an outage ;P | 09:31 |
| stub | lifeless: Yes, we can define outage in such a way as to not have outages :-) | 09:32 |
| lifeless | stub: \o/ at shifting goalposts | 09:32 |
| stub | lifeless: The important things are backup processes, slon processes etc. and they are protected as we define this stuff as system users. | 09:33 |
| lifeless | yes | 09:33 |
| lifeless | stub: so my thrust is to reduce/eliminate failed fdt's where we miss the window and don't do the deploy | 09:34 |
| stub | Increasing the long running transaction definition is the simplest thing that might fix the immediate problem, and I think it is even a command line option. | 09:34 |
| lifeless | balls in your court :) | 09:34 |
| stub | For killing long running transactions, we should be able to do the connections to the slaves. On the master, it would be all or nothing as I can't tell a read only connection from a read/write. | 09:35 |
| lifeless | we had in a row that failed IIRC | 09:35 |
| lifeless | stub: can we not check held locks? | 09:35 |
| stub | That might work, yes. | 09:35 |
| stub | There are race conditions, but we already have that with connections that don't meet the 'long running' criteria but might cause problems when we take down pgbouncer. | 09:36 |
| bigjools | poolie: I don't know precisely but we have done a couple of fixtures that start up with "make run" now, see rabbitfixture and txlongpollfixture | 09:37 |
| bigjools | poolie: allenap did the work if you need details | 09:37 |
| bigjools | poolie: although I suspect the buildd package will need some tweaking as it's currently designed to run in a chroot in its own account | 09:38 |
| poolie | right, and some of it insists on being under xen | 09:38 |
| poolie | do you test it locally at all? | 09:38 |
| bigjools | poolie: not as such, I am talking about running it locally | 09:38 |
| bigjools | yes - so you make a new "buildd" account and then chroot inside there | 09:38 |
| lifeless | stub: there should be one lock on the virtual xaction and thats it, for a readonly op IIRC | 09:39 |
| * bigjools OTP for 5m | 09:39 | |
| stub | lifeless: Right, I haven't looked closely yet but anything that doesn't have any sort of exclusive locks open would count I think. | 09:39 |
| stub | lifeless: So I guess we can just ignore any read only transactions for the long running check and keep everything but that query the same. | 09:41 |
| stub | masters and slaves. | 09:41 |
| poolie | bigjools, could you read https://code.launchpad.net/~mbp/launchpad/800295-buildd-split/+merge/81111 | 10:17 |
| bigjools | poolie: OTP, will check shortly | 10:18 |
| poolie | thanks | 10:18 |
| === nigelb_ is now known as nigelb | ||
| bigjools | poolie: where is _hasDaemonStarted called from? | 11:12 |
| poolie | bigjools, from the superclass TacTestSetup | 12:25 |
| bigjools | poolie: that's code that's still in the main tree | 12:26 |
| bigjools | poolie: I think we need to duplicate TacTestSetup in buildd | 12:27 |
| poolie | oh probably | 12:28 |
| poolie | if we want the split out buildd to be independently testable | 12:28 |
| bigjools | indeed | 12:28 |
| poolie | ... with tests that cover starting it this way | 12:28 |
| bigjools | LP can depend on buildd but not the other way around | 12:28 |
| poolie | and we probably do | 12:28 |
| bigjools | thanks for looking at this though! | 12:29 |
| poolie | i have ec2 seeing if it passes with these changes now | 12:30 |
| jelmer | rvba: hi, do you have time for a review? | 12:57 |
| rvba | jelmer: sure. | 12:57 |
| === rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba | Critical bugtasks: 266 | ||
| jelmer | rvba: great - the MP is at https://code.launchpad.net/~jelmer/launchpad/stacked-code-imports/+merge/81139 | 13:01 |
| deryck | Morning, everyone. | 13:01 |
| jelmer | hey Deryck | 13:02 |
| rvba | jelmer: okay, I confess I'm not familiar with this part of the code but it will be a good occasion to learn. Besides this branch has sort of already been approved right? | 13:03 |
| jelmer | rvba: yeah, benji reviewed it earlier | 13:03 |
| rvba | jelmer: Okay, I'll have another look then. | 13:04 |
| flacoste | bigjools: can you join the session going on in #ubuntu-uds-bonaire5 ? | 13:13 |
| flacoste | bigjools: we are discussing gating uploads when the distro is in prerelease | 13:13 |
| Ursinha | I wish I was there *sigh* | 13:14 |
| jml | I'm creating a Launchpad project now | 13:28 |
| jml | and setting up team structures is a bit dull | 13:28 |
| jml | and easy to mess up | 13:28 |
| === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba, jcsackett | Critical bugtasks: 266 | ||
| jml | Could I please get a team renamed? https://answers.launchpad.net/launchpad/+question/177395 | 13:31 |
| Beret | jml, I'm pretty sure that costs $19.95 plus S/H | 13:33 |
| jml | Beret: Canonical can dock it from my salary then. | 13:34 |
| Beret | hah | 13:34 |
| rvba | Morning jcsackett! | 13:35 |
| jcsackett | morning, rvba. :-) | 13:36 |
| rvba | I'm afraid it's gonna be a crazy reviewing day. | 13:36 |
| rvba | I'm on Jelmer's branch, then I'll review Ian's 1249 branch. | 13:37 |
| rvba | After that I plan to kill myself ;). | 13:37 |
| rvba | 1249 lines branch that is. | 13:37 |
| jcsackett | rvba: 1249? that's not a typo? wow. | 13:38 |
| jcsackett | rvba: i'm looking at your branch now. | 13:38 |
| rvba | jcsackett: Thank you. | 13:38 |
| jml | Is https://bugs.launchpad.net/launchpad/+bug/3945 different from https://bugs.launchpad.net/launchpad/+bug/57418, really? | 13:45 |
| _mup_ | Bug #3945: Support debtags in Launchpad for products and packages <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/3945 > | 13:45 |
| _mup_ | Bug #57418: Support debtags in Packages.gz <escalated> <feature> <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/57418 > | 13:45 |
| deryck | abentley, my css-polish branch is up to date now and pushed. | 13:45 |
| === fjlacoste is now known as flacoste | ||
| abentley | deryck: thanks! | 13:48 |
| deryck | np! | 13:48 |
| jelmer | jml: it seems they're pretty similar. debtags in their original implementation were not in the Packages file, so it would be possible to do 3945 without 57418 | 13:50 |
| jml | jelmer: ah, ok. | 13:50 |
| abentley | rvba, what do you mean by "unify the formatting here"? | 13:54 |
| rvba | abentley: Well, it looks like sometimes the inner part is indented, sometimes not. | 13:54 |
| abentley | rvba: okay. | 13:55 |
| deryck | rvba or jcsackett, I have a CSS/html branch for review. takers? :) | 13:56 |
| abentley | rvba: better? http://pastebin.ubuntu.com/727255/ | 13:57 |
| rvba | deryck: We will add it to the queue :) | 13:57 |
| rvba | abentley: I think so, don't you agree? | 13:58 |
| deryck | rvba, ok, cool. A busy day then, I take it. :) | 13:58 |
| abentley | rvba: I waffle about indenting. | 13:58 |
| jcsackett | deryck: a bit. i should be able to look at yours in a bit. | 13:59 |
| rvba | deryck: busy day indeed. | 14:00 |
| rvba | jcsackett: just for the fun of it, I invite you to take a look at the MP: https://code.launchpad.net/~wallyworld/launchpad/delete-bugtask-ui-ajax-878909/+merge/80779 | 14:02 |
| jelmer | rvba: thanks! | 14:03 |
| rvba | np | 14:03 |
| jcsackett | i will just say i'm glad you're taking that one, rvba. :-P | 14:04 |
| rvba | hehe | 14:04 |
| jcsackett | rvba: r=me on your branch. | 14:07 |
| jcsackett | deryck, i'll look at yours now. | 14:07 |
| deryck | jcsackett, ok thanks! | 14:08 |
| rvba | jcsackett: thanks. The nice part is that landing this branch will conflict with Ian's branch. | 14:08 |
| rvba | I have my revenge! | 14:08 |
| * jcsackett laughs. | 14:08 | |
| jcsackett | that's the problem with enormous branches -- the odds of someone stepping on your toes goes *way* up. | 14:09 |
| rvba | True | 14:09 |
| jcsackett | deryck: to make sure i understand, your css changes only effect the mustache template, right? | 14:11 |
| deryck | jcsackett, correct | 14:13 |
| jcsackett | awesome. r=me, then, deryck. | 14:13 |
| deryck | jcsackett, rocking thanks! | 14:13 |
| allenap | rvba, jcsackett: Please can you review my shortish branch? https://code.launchpad.net/~allenap/launchpad/participation-keyerror-bug-810114-2/+merge/81151 | 14:21 |
| jcsackett | allenap: sure, i'll jump that over the longer branch of jtv's i just grabbed. | 14:22 |
| allenap | jcsackett: Hehe, thanks. | 14:22 |
| deryck | abentley, my css-polish branch is approved and playing in ec2 now. | 14:23 |
| abentley | deryck: excellent. | 14:24 |
| jcsackett | allenap: i haven't seen the "slurp" function before, what's the deal? | 14:24 |
| jcsackett | ... or is this defined elsewhere in the branch ... | 14:24 |
| allenap | jcsackett: The latter :) | 14:24 |
| abentley | deryck: I expect to have this branch up for review today. | 14:25 |
| deryck | abentley, awesome. | 14:25 |
| * deryck goes offline to switch work locations, back shortly | 14:31 | |
| jcsackett | allenap: r=me. | 14:31 |
| allenap | jcsackett: Thanks! | 14:31 |
| abentley | rvba or jcsackett: could you please review https://code.launchpad.net/~abentley/launchpad/client-bug-fields/+merge/81157 ? | 15:27 |
| rvba | abentley: I'll take it. | 15:28 |
| abentley | rvba: thanks. | 15:28 |
| abentley | deryck: custom-bug-listings-css-polish fails lp.bugs.browser.tests.test_bugtask.TestBugTaskSearchListingView.test_mustache_rendering | 15:38 |
| deryck | abentley, ah, dang. I didn't run tests. But ec2 will catch it. | 15:38 |
| deryck | abentley, thanks for the heads up. I'll get a fix shortly. | 15:38 |
| abentley | deryck: np. | 15:39 |
| abentley | deryck: let me know so I can merge the fix. | 15:39 |
| deryck | abentley, will do | 15:39 |
| adeuring | rvba, jcsackett: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/banner-for-beta-features/+merge/81165 | 15:42 |
| jcsackett | adeuring: i'm doing one of jtv's right now, i can do yours right after. | 15:42 |
| adeuring | jcsackett: trhanks! | 15:42 |
| rvba | jcsackett: I told you today would be crazy ;) | 15:43 |
| jcsackett | rvba: you weren't kidding. :-P | 15:43 |
| jcsackett | adeuring: okay, i'm looking at yours now. | 15:49 |
| adeuring | jcsackett: cool | 15:49 |
| === beuno is now known as beuno-lunch | ||
| deryck | rvba or jcsackett, I have another branch for review if either of you is available. | 15:59 |
| rvba | deryck: I'll take it once I'm finished with the one I'm working on right now. | 15:59 |
| deryck | rvba, thanks! It's here: https://code.launchpad.net/~deryck/launchpad/orderby-bar-settings-slot/+merge/81148 | 16:00 |
| rvba | k | 16:00 |
| deryck | abentley, test is fixed now and pushed up to lp in that branch. | 16:13 |
| abentley | deryck: thanks. | 16:14 |
| deryck | np | 16:14 |
| rvba | abentley: I've got a question about this bit of code: http://paste.ubuntu.com/727380/ | 16:15 |
| abentley | rvba: sure. | 16:16 |
| rvba | in the each loop, what kind of value have the variables value and key? | 16:16 |
| abentley | rvba: value is a boolean, key is a string. | 16:17 |
| rvba | abentley: field_visibility is something like {show_item: true} right? | 16:18 |
| abentley | rvba: right. | 16:18 |
| bigjools | any idea why I'd get a "Signature couldn't be verified: (7, 8, u'Bad signature')" when reviewing an MP over email? | 16:18 |
| jelmer | bigjools: are you using thunderbird without MIME? | 16:19 |
| bigjools | jelmer: no | 16:19 |
| rvba | abentley: then I don't get why you do: delete batch.mustache_model.bugtasks[i][key]; | 16:19 |
| bigjools | the signature verifies locally (I am using kmail) | 16:19 |
| rvba | abentley: could you please explain that a little bit? | 16:19 |
| jelmer | bigjools: I'm finding that if I don't use MIME for GPG signatures in Thunderbird I get that error | 16:19 |
| bigjools | jelmer: I have no idea if I can even config that | 16:20 |
| abentley | rvba: that is to prevent "batch.mustache_model.bugtasks[i][key]" from shadowing "batch.mustache_model[key]" | 16:20 |
| bigjools | jelmer: ah I found something - so "S/MIME" ought to work? | 16:21 |
| abentley | rvba: mustache templates are supposed to have nested scopes, so that if key isn't found in current scope, it's looked up in the outer scopes. | 16:22 |
| rvba | abentley: ah! that's what I was missing! | 16:23 |
| rvba | Thanks! | 16:23 |
| abentley | rvba: np. | 16:23 |
| bigjools | jelmer: I've not used MIME before and it's worked, plus kmail bitches that it doesn't have the other side's keys if I try and force MIME :/ | 16:24 |
| jelmer | bigjools: that works for me, though it's obviously also a bug in launchpad if it only works with S/MIME (in some situations?) | 16:25 |
| rvba | abentley: r=me | 16:25 |
| abentley | rvba: thanks. | 16:25 |
| adeuring | jcsackett: thanks for your review! | 16:26 |
| rvba | deryck: I'm starting with your branch. | 16:26 |
| jcsackett | adeuring: you're welcome, sorry i forgot to tell you i was done. :-P | 16:26 |
| adeuring | np ;) | 16:26 |
| deryck | rvba, thanks! | 16:26 |
| rvba | deryck: r=me | 16:38 |
| deryck | rvba, thanks! | 16:39 |
| rvba | np | 16:39 |
| === rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugtasks: 266 | ||
| === beuno-lunch is now known as beuno | ||
| lifeless | moin | 18:07 |
| bigjools | good night! | 18:13 |
| abentley | deryck: looking at bug age, the examples seem to show a time formatting we haven't done before. Or am I missing something? | 18:17 |
| deryck | abentley, yeah, I thought that was new as well, but never asked about it. | 18:17 |
| === Pendulum_ is now known as Pendulum | ||
| === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 266 | ||
| lifeless | mrevell: I'm ready whenever | 19:43 |
| mrevell | hey lifeless! | 19:44 |
| timrc | cody-somerville, #ubuntu-uds-Bonaire4 | 21:40 |
| lifeless | wow oops pruning is ... just wow | 22:29 |
| poolie | lifeless, so my split-out-buildd thing has passed tests up to a certain level of completion | 22:47 |
| poolie | the buildd tests still depend on the lp tree but there is no actually copied-around code | 22:48 |
| timrc | I noticed that from a logged out perspective my ~canonical membership badge is not shown on my profile page. Is this by design? Or, is it a bug? Or, am I missing how to show it? | 22:51 |
| lifeless | timrc: canonical is a private team | 22:51 |
| timrc | lifeless, so can someone logged in but not a member of Canonical see it? | 22:53 |
| lifeless | no | 22:54 |
| timrc | lifeless, okay, that's the information I needed | 22:54 |
| wgrant | lifeless: Yeah, oops-prune is pretty special. | 23:02 |
| wgrant | lifeless: I don't imagine wildcherry is very happy with it. | 23:02 |
| StevenK | wgrant: I need to write an API script to copy from Ubuntu? I forget. :-( | 23:02 |
| lifeless | so, I'm considering some options here | 23:03 |
| lifeless | I need opinions :) | 23:03 |
| lifeless | broadly, I'm thinking: | 23:03 |
| lifeless | - delta based - get changes across the tables for a date range | 23:03 |
| wgrant | StevenK: You can copy from anywhere. Even create a new PPA and copy from an existing PPA into that. | 23:03 |
| lifeless | - use [for now] a local disk file to record last run time | 23:03 |
| lifeless | - add an API on project [product] that takes two dates - start and stop - and returns a set of oops ids | 23:04 |
| lifeless | of course, this is probably impossible in the API | 23:04 |
| lifeless | StevenK: wgrant: either of you familiar with api gotchas / benefits ? | 23:05 |
| lifeless | if I just return a set([id, id2, ...]) from a method, will it work | 23:06 |
| wgrant | That should work, yes. | 23:06 |
| lifeless | or do I need an Interface OopsResult with an attribute oops_ids ? | 23:06 |
| wgrant | But doing this through the lazr.restful API would indicate that you have a deathwish. | 23:06 |
| lifeless | well | 23:06 |
| lifeless | I'd like to let other folk running oops systems work with LP to keep interesting ones and prune the rest. | 23:06 |
| lifeless | So there is very good reason to make this a public API | 23:07 |
| wgrant | Yes, there is very good reason to do it. | 23:07 |
| wgrant | But there's also very good reason to not. | 23:07 |
| lifeless | ... | 23:07 |
| wgrant | This sounds like it's going to be a fairly expensive method, and return a lot of data. | 23:08 |
| lifeless | no | 23:08 |
| wgrant | Neither of which the API is likely to be good at. | 23:08 |
| wgrant | Ah, if it's partial, I guess. | 23:09 |
| lifeless | there are very few oopses referenced in the system for any given short date range | 23:09 |
| lifeless | the reason it takes 3 minutes to run is because we're searching everything | 23:09 |
| lifeless | searching 1 day - one /(365*5) of the db - should be subsecond trivially. | 23:09 |
| wgrant | Indeed. | 23:09 |
| wgrant | So, yes, you can just return a sequence from a method, and it will work. | 23:10 |
| lifeless | and if not, there are other similar uses so making it subsecond is desirable anyhow. | 23:10 |
| wgrant | You can't declare the return type, so lazr.restfulclient won't do any special decoding. | 23:10 |
| wgrant | But since it's just strings it should be fine. | 23:10 |
| lifeless | the client script then needs to remember where it has pruned up to - thats the lower bound, and select a day more than (gc window) back, thats the upper bound. | 23:11 |
| lifeless | so, for instance, if I default to 7 days, the first run would take the oldest datedir in the local datedir repo, and 7 days ago, and query. | 23:11 |
| lifeless | which would suck, if we ran it on the old stuff on carob | 23:11 |
| lifeless | but new stuff will be a few weeks. | 23:12 |
| lifeless | max. | 23:12 |
| poolie | lifeless, wgrant, what do you think of me landing https://code.launchpad.net/~mbp/launchpad/800295-buildd-split/+merge/81111 as an incremental step towards a buildd split out | 23:38 |
| === wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Critical bugtasks: 266 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
