[00:44] wgrant, wallyworld: Did either of you follow the email thread from curtis about represting the security/privacy policies as something like tags? Are we essentially back to something like: http://people.canonical.com/~huwshimi/policy2.png ? [00:45] huwshimi: not sure. that ui has issues also eg tags should be separately editable [00:46] and it doesn't scale so well i don't think [00:49] wallyworld: It won't scale because that list could become quite long? [00:49] wallyworld: The list of policies, I mean [00:49] huwshimi: yes [00:49] hmmm [00:50] wallyworld: Any suggestions about what might work? [00:50] not really off hand. it's hard to concisely represent all the info isn't it [00:50] At present there is probably only going to be 1-4 policies. [00:51] I don't really have any suggestions :/ [00:51] 'tis difficult. [00:51] that's still going to be a lot of text [00:51] perhaps the table cells could be a list of policies, one under the other [00:52] wallyworld: Yeah, just what I was typing [00:52] more vertical space per row, but nicer looking? [00:52] and each could then have an edit icon next to it [00:52] wallyworld: OK I'll mock that upo [00:52] *up [00:53] oko [00:53] :-P [00:53] if it's treated tag like, why not something like a tag control that builds a little ui around each so that it helps break them up/make them distinct? [00:54] it's the "excessive" use or horizontal space i think that's one issue [00:54] arranging vertically should help perhaps [00:55] I guess the difficulty with the tag idea is that we have to display both the policy and the permission, and this makes it a more complicated construct [00:55] is it possible to icon-ify one part? [00:56] if there's only a couple permissions Restricted/Not restricted and such? [00:57] rick_h_: That's a possibilty, one concern is that the permissions are fairly complicated to understand as they are... [00:58] gotcha [00:59] I know when I've got too much info I tend to try to color/icon part and text the other, or somehow break it apart [00:59] especially if they can combine in different ways [00:59] and i think we have a usability policy of avoiding icons where the user needs to guess or know their meaning? [00:59] but I've not seen the permissions stuff yet [01:00] yea, that's true, and doesn't look like there's a solid tooltip/helper function in place in the first couple of things I check out [01:03] reliance on tooltips is also best avoided for accessibility too afaik [01:05] Not just accessibility, but anything that doesn't have a mouse. [01:05] eg. phones/tablets [01:05] right [01:36] wallyworld, wgrant: Hmmm... http://people.canonical.com/~huwshimi/policy6.png or http://people.canonical.com/~huwshimi/policy7.png or http://people.canonical.com/~huwshimi/policy8.png are all options, but I don't feel like I'm getting anywhere good. [01:37] I really don't know :/ [01:37] 6 is the best of those i think [01:37] how often will people have more than one? [01:38] Has there ever been discussion around the concept of upload/build hooks for PPAs? I would like some way of telling a service downstream of Launchpad to take an action, rather than having it poll Launchpad [01:38] I have no idea how this could be implemented in a safe manner, though [01:38] timrc: pubsubhubbub [01:38] It depends. For Ubuntu, most people will have at least two. For other projects, most people will probably have one. [01:39] so i think vertical stacking will work ok [01:42] lifeless, neat, reading about it now [01:44] wallyworld wgrant: I can't really think of any other options right now, so I might propose these options for now unless there's anything else either of you can think of now? [01:44] huwshimi: i can't, but i'm sure others will have strong opinions [01:47] wallyworld: haha, I'm sure they will [01:47] wallyworld: I'm sure there will be lots of vague "just putting it out there" opinions too. [01:51] huwshimi: from that ui, does edit have controls to change or can you just remove the permission? [01:53] lifeless, so if I understand this correctly, LP would need to provide the feed, is this something that you guys are working on or wanting to work on? I imagine this gets a little more complicated in my case where I'm dealing with P3A's [01:54] rick_h_: I believe the edit screen has an option remove in the same way the "assigned to" picker on a bug does [02:06] lifeless: https://pastebin.canonical.com/55760/ do you have any clue why the evaluation of an attribute (person.name) would end up creating a different Request object when calling checkPermission and not use self.request from the view, causing the permission caching to fail? [02:08] huwshimi: what do you use for mockups? [02:09] rick_h_: Inkscape [02:09] ah cool, was trying out a bunch of web/etc ones and didn't find one I was 100% happy with [02:11] wallyworld: IWebServiceClientRequest may well be killing some thread-local. [02:11] wgrant: ok, i'll see if taking that away helps [02:12] Worth a try. [02:12] rick_h_: Yeah, there are plenty of decent options out there, just need to find something you're comfortable with [02:12] i then would need to figure out how to replace it [02:17] wgrant: still broken sadly [02:17] wallyworld: That's upsetting. [02:17] yep. nothing obvious that i can see [02:17] wallyworld: Oh [02:18] IndirectSubscribers? [02:18] ARe you sure that's what you want? [02:18] That's structural subscriptions, mostly. [02:19] you mean do we want to print the names of private teams which are indirect subscribers? [02:19] Well, what are you testing? [02:20] that the subscription portal showing direct and indirect subscribers does not render for private teams [02:20] whether direct or indirect [02:20] What suggests that the caching is failing? [02:20] Indirect subscriptions are shown ? [02:20] i've traced the code execution [02:21] the caching call add the permission to self.request [02:21] the person.name eval ends up in the permission checking code and a totally different request is checked to see if the permission exists on that request [02:21] Ah] [02:22] when i say request, i mean request instance [02:22] How are you calling the view? [02:22] In a browser? [02:22] using LaunchpadFormHarness [02:22] i copied an existing test [02:23] That may well not set the thread-local request. Do other permission caching tests do it that way? [02:23] well it seems to be a wrapper around create_view and friends and tests using create_view directly work i think [02:24] i'll have to double check [02:26] the tests for precache_permission_for_objects() simply create a LaunchpadTestRequest and do a login [02:27] i've got some other tests which call create_initialized_view [02:28] so long as a pass the same request used when calling login() to the create view, it works [02:29] Right, that makes sense. [02:29] Semi-thread-locals ftl. [02:33] makes sense. but doesn't explain why eval of person.name wants to create its own, different request instance [02:34] It should be using the thread-local. [02:35] Whereas precache_permission_for_objects is using the one given to the view. [02:35] They could well be different when the view is called. [02:38] Hmm. [02:39] bitbucket and github's privacy controls are somewhat more limited than I expected. [02:39] wallyworld, huwshimi: Have you looked at them at all? [02:39] no [02:40] Issue privacy is on a project basis. [02:40] So either the project's issues are public, or they are private. [02:41] There's no equivalent of our restricted observer concept. [02:41] Everyone can see everything, or only nominated people can see everything. Nobody else can see anything at all. [02:42] wgrant: Github's privacy is a little bit clunky as well. [02:42] Groups are also namespaced within an account. [02:42] Its per repo. and you need to keep creating teams [02:42] Yeah. [02:42] I haven't explored GitHub yet, since they don't have free private repos. [02:42] Most people don't use it, so there are less complaints. [02:42] I hear about this often from Mozilla folks who do use it. [02:43] The Private and public repos have the same repo organization. Except the private one has that flag ticked to private :)] [02:43] bitbucket has a very simple, easy, fast, but extremely limited privacy system. [02:44] nigelb: Are GitHub groups per-repo, or per-account/organization? [02:44] bitbucket's are per-account, not per-repo. [02:44] github is organization->repo [02:44] Per organization [02:45] https://github.com/pylons is an example, organization, list of repos, and then users part of the org [02:45] wgrant: No I haven't seem them [02:45] I know roughly how their organizations work, but I can't see groups. [02:45] Are groups only accessible to the org owners? [02:45] Yeah [02:45] and admins [02:46] wgrant: got it to work by ditching LaunchpadFormHarness and using create_view directly [02:47] and i see that canonical_url(naked_subscriber, rootsite='mainsite') gives a different result to canonical_url(naked_subscriber) [02:47] Right, by default it will use the current rootsite. [02:47] first one gives http://launchpad.dev/xxx, the second, http://127.0.0.1/xxx [02:47] fmt:url used to do the same, but now it defaults to mainsite for projects/distributions/people. [02:48] perhaps everything should do tyhat [02:48] makes more sense [02:48] Well, it will be moot soon. [02:48] Because !mainsite will cease to exist. [02:48] yeah [02:48] \o/ [02:49] Define 'soon'? :) [02:49] Undefined as yet. [02:51] Also, are you working on changing Launchpad's private branches structure? [02:51] We're working on changing just about everything relating to privacy. [02:51] Do you have anything in particular in mind? [02:52] Nah. I remember you telling its very bad. [02:52] If you're fixing, that's very good news :) [02:59] lifeless: Have you had a chance to look at my MP yet? [03:00] rick_h_: I take it you had a good first day, after we scared you in #launchpad ;) [03:09] Hah [03:09] bitbucket's email notification broker lets you specify any email address. No verification. [03:10] #win [03:14] nigelb: good start. Head swimming a bit [03:15] heh [03:15] That sounds like my first few days of trying to patch LP. [03:16] yea, I mean the toolchain is about opposite of everything I've used the last few years. [03:16] so when everything is foreign, lots of docs to read/reference [03:18] Ah, Pylons, I see. [03:18] yea, pylons, pyramid, sqlalchemy, mako [03:19] jquery, though I have tinkered with YUI and like it a lot [03:21] There's been a bit of debate around the company about whether YUI is still the right choice. The consensus seems to be that they're pretty similar, except that YUI requires a bit more structure/setup to start off, but that's probably beneficial in the long run. [03:21] I don't have too strong an opinion, but I tend to agree. [03:21] YUI vs ? [03:21] jQuery, of course :) [03:21] oh, I'd not say they simliar. [03:22] Aren't really any other contenders at the moment... [03:22] Similar in terms of ease of use once you're going. [03:22] I just got through ranting on jquery at a conference only to find out one of the guys in the group was a core contrib of jquery [03:22] oops [03:22] Heh [03:22] the tooling, organization, and built in structure is a big win in YUI [03:22] Yes. [03:22] to compete you'd have to get jquery + requirejs + backbonejs + historyjs [03:22] and start stacking together like a mad men [03:23] I've started the move myself with my OSS bookmark app [03:23] the big win for jquery is that low inertia to get started and just size of community [03:23] Exactly. [03:23] But that seems to be about all it has going for it. [03:24] but then again, I hear the same things about PHP, and I don't care to use that any more either :) [03:24] I'll have to catch the next time the debate starts up, I'm good at those heh [03:27] heh [03:27] I hated YUI when I had to use it for the first time. [03:27] well I took the long path there. jquery -> dojo (ugh) -> YUI and kind of 3 bears situation [03:28] one was too light, one was too "java" feeling, YUI seemed just right [03:28] It's very much like PHP/Java/Python, I think. [03:28] but 90% of the places I've worked has been all jquery, so definitely know how it goes [03:29] I like to use that comparison, the core jquery dev thought it was a bit unfair though [03:29] PHP and jQuery make it very easy to hack stuff together quickly, but you're setting yourself up for pain. [03:29] but I'm picky I guess, I don't care for django either [03:29] I hate Django. [03:29] Pyramid looks pretty nice, from what I've seen. [03:29] yet it's the big popular kid on the block [03:30] yea, I really liked pylons because there wasn't a ton to it. You could really read/understand/trace the code nicely [03:30] pyramid puts a bit more on top, but it's some good bits [03:30] Chris over there is really good about code quality, testing, and all that [03:30] And it reuses the good bits of Zope. [03:30] right [03:30] nice thing is it makes stuff like zcml optional [03:31] You know what they say, "those who don't understand Zope are doomed to reinvent it, poorly". [03:31] routes vs traversal, all that [03:31] *cough* Django [03:31] wgrant: *hah* [03:31] Right. But IIRC it's flexible? [03:31] very [03:31] wgrant: you won't like the conclusion I've been coming to vis-a-vis django [03:31] repoze.bfg certainly did both when I last looked at it. [03:31] lifeless: Oh? [03:31] which is the downfall for many. They want to be told "You will put that code there! and only use that tool!" [03:31] wgrant: the leanness makes it easy to write efficient code [03:32] wgrant: something I am very pro [03:32] makes the docs harder to get into since you have to choose your own adventure [03:32] lifeless: Have you looked at Pyramid (or repoze.bfg, its predecessor)? [03:32] I can never get past django orm and templates. [03:32] They're lightweight. [03:32] it's like making me use eclipse because it's got all the prebuilt buttons for things [03:32] They don't impose nasty stuff on you, like Django. [03:32] Yes. [03:32] wgrant: I need to have a re-look, last I looked a repoze.bfg it was still built around objects-are-cheap [03:33] wgrant: Which is an inappropriate structure for the real world [03:33] lifeless: pyramid has travelled a bit from repoze.bfg days [03:33] lifeless: A bit, as anything Zope based is sort of going to lean toward. But it's rpetty flexible. [03:33] Unlike classical Zope 3, it doesn't pretend that ZODB is the solution to all problems. [03:33] OTOH settings.py must DIAF. [03:33] but again, with that it's a lot about the tools you couple it with [03:33] Right. [03:33] But in Django you have no choice, really. [03:34] <3 mako and SA [03:34] It all comes along. [03:34] wgrant: its not zodb so much as the culture of code structure that evolved *because* of zodb [03:34] bah, 90% of pyramid users aren't zodb [03:34] Right, but stuff like Zope security is very object-oriented. [03:34] rick_h_: I'm not sure the % matters TBH [03:34] Which causes as huge trouble. [03:34] s/as/us/ [03:35] yea, that's put together kind of interesting [03:35] there's the zope stuff with full __acl__ and traversal support in there [03:35] but there are places it gets kind of hooked into for the rest of us [03:35] you end up writing more of your own auth I guess [03:36] but at least they're not entirely reinventing it [03:36] Django works OK if you can work inside the framework and don't need to do anything very special. [03:36] yea, for the small one off sites I see the use case [03:36] But if you want a non-hopeless ORM, or a different template system, or non-trivial security... [03:36] You're stuffed. [03:36] at least they've finally bought into wsgi ;) [03:37] You have to throw out half the rest of the framework, or implement it yourself, but the unused bits of the framework sit around haunting you and breaking and obstructing things. [03:37] wgrant: the djagno orm appears to be easier to drive that storm, for bulk loading. Just saying. [03:37] lifeless: Hm, not when I last looked. [03:37] Admittedly that was a while ago. [03:37] multiple fk models...the end [03:37] it has some graph traversal primitives [03:38] Also, Storm is not exactly the model of perfection any more. [03:38] I gave a SA tutorial at PyOhio, one of the top 5 reasons to use Python is to get access to SA imo [03:38] Storm was written back when SA wasn't so good. [03:38] And the only real alternative was SQLObject, which was even worse. [03:39] yea, I remember when storm came out doing the side v side and such [03:39] lol, then turbogears went from SO to SA was a good day :) [03:39] /then/when [03:39] LP still uses Storm's SO compat layer in lots of places, unfortunately. [03:39] There's a *lot* of code to migrate. [03:40] yea, that's what I heard today [03:42] well, should head out if I'm going to get back in the morning [03:42] thanks for the tool talk :) [03:42] See ya. [03:51] wgrant: the djagno orm appears to be easier to drive that storm, for bulk loading. Just saying. [03:51] really? [03:52] oh i think you mean something other than what i thought by bulk loading [03:54] mwhudson: getting a subset of the objectgraph where depth > 1 [03:54] yeah, i thought you meant "getting a lot of data into the db" [03:54] select_related and prefetch_related indeed look quite handy. [03:55] because django is pretty awful at that [03:59] huwshimi: Yes! Kill the default bug listing! [03:59] It is pointless. [04:07] mwhudson: Hm, have you seen GitHub's Deploy Keys? [04:14] wgrant: no [04:15] wgrant: hey, that looks a little familiar [04:15] mwhudson: Indeedily. [04:17] heh [04:17] mwhudson: :) [04:17] Is that mwhudson did sometime back? [04:17] well, i talked about something like that [04:18] *that what. [04:34] hmm... how might I figure out all the situations where Launchpad sends emails? Is there a function I can grep for? [04:34] sendmail [04:34] I think [04:35] It's quite a disgusting function [04:35] There are a number of abstractions on top of that, though. [04:35] Just to make matters difficult. [04:36] that's ok, that should be enough for me to get started [04:38] wgrant: s/difficult/moar fun/g [04:39] :) [04:48] jtv: Oh! Did anything happen with your SPN speed-up branch? [05:05] StevenK: good point. Want it? I'll assign it to you. [05:05] Happen to have a bug for this? [05:06] If not, I'll just file one. [05:06] I do not have a bug for it. [05:06] jtv: wgrant is OCR today *cough* [05:06] jtv: I'd just like to read the diff [05:06] OK, coming up. [05:07] I'll ping you when it's ready for reading. [05:07] lifeless: Still lurking? [05:07] jtv: Danke [05:14] yes [05:14] your branch is pending [05:14] tell me, have we tested bug / branch search overhead with it ? [05:15] I haven't tested bug/branch searches on production data with this iteration of the schema. [05:17] But it should be underhead, not overhead. [05:18] !data [05:18] bbs [05:18] Shh [05:25] StevenK: still waiting for the diff to update, but it's at https://code.launchpad.net/~jtv/launchpad/bug-890542/+merge/82241 [05:25] And there it is. [05:25] wgrant, care to review it? [05:28] jtv: One thing I wanted for the garbo job is it logging how many {B,S}PPHs it has updated. [05:29] okokok [05:30] jtv: The SPPH __call__ checks for completedness twice. [05:30] The check at the end was removed from BPPH, but for SPPH it was replaced with something else. [05:30] Ah, thanks. [05:31] That's a redundant line now. [05:31] I also don't think the SPPH/BPPH aliases are worth it, particularly when you can use find()'s short form. [05:32] jtv: Are you using DF at the moment? [05:32] Only running process-upload on it. I can stop that. [05:32] Once the UK comes online I'm hoping to get the buildmaster test going again. I'll need my local code changes for that. [05:33] I don't want to touch the code, just to do touch the DB in bad ways. [05:33] Which will involve taking out locks on most bug/branch rows for a while, etc. [05:34] No skin off my nose. [05:34] As long as I can get back to testing the buildd stuff in a few hours. [05:34] Ah, bah. drivers is a list [05:35] stub: do we have access to the affected-rows count after a Store.execute? If so, where? [05:35] jtv: Er? len(spphs) ? [05:35] Hmm yeah, you're right. [05:36] jtv: That's what I suggested it -- it's cheap. [05:36] s/\(wh\)at/\1y/ [05:37] Can I just logging.getLogger('populate-bspph-bspn')? [05:37] self.log is set, I think [05:37] self.log.info() ... [05:38] On the TunableLoop? [05:38] Ah yes. [05:38] Mind you, I wrote this stuff. [05:39] My genius is overshadowed only by my incompetence. [05:39] If I have climbed higher, it was by standing on the faces of giants. [05:39] Because the face is higher than shoulders? [05:42] And it's more demeaning. No point being a bigger fish if the pond has room enough for the others. [05:42] jtv: I think so, yes. I think I made it the return value of Store.execute() if the no-result-set option is passed? [05:42] * stub has a look [05:42] stub: turns out we don't need it just now, but may be useful to be aware of anyway. [05:43] jtv: Search for rowcount in lp/scripts/garbo.py - first hit is an example. [05:43] Argh rowcount. I was thinking affected_rows. [05:43] jtv: it isn't the return value. It is an attribute on the return value. [05:44] Yes… just saying I did grep but for the wrong identifier. :/ [05:46] StevenK, wgrant: diff has updated [05:50] jtv: Approved. [05:50] thanks! [05:51] I do resent the discriminatory comment though. You will be hearing from HR. [05:51] Haha [05:51] Note the spacing between those sentences—take that! [05:54] Oh, the persecution around here. This is just like the time when we were ridiculed for knowing SQL's inequality comparison operator. [06:05] lifeless, stub: some nice news on foreign-key locks. There's postgres work going on that should effectively eliminate the problem. The complexity of the change worried me (will it really be completed?) so I proposed a simpler solution, which so far has been received well. [06:51] \o/ [07:00] stub, for background if you're interested: the ongoing work was to add a special lock type, which I think is worrisome because of the many lock interactions and O(n²) correctness problems etc. [07:01] jtv: Just looked at the thread. [07:02] jtv: Just need it implemented and backported to 9.1 :-) [07:02] Sounds easy. :) [07:02] And then, of course, we'd need to set immutable constraints on our key columns. === jtv is now known as jtv-afk [07:11] jtv: thats a no brainer for all our serial primary keys. a little thought might be required for tables without id, but I suspect all of them would be good to go too. === jtv-afk is now known as jtv [07:38] stub: That's what I figured — easiest way to avoid key update conflicts is to disallow updating them, and how often do you want to update keys of anything in normal operation? Schema documentation alone could make an immutable index nice-to-have. [07:39] jtv: Yes. Especially if you are using a key for external systems (eg. a component in a URL you don't want to change) [07:39] Hmm yes [07:40] I wonder what other opportunities might open up if an entire table were covered by immutable constraints. [07:41] jtv: Might make partitioning safer too [07:41] Yeah. Replication might be a bit easier, though the code's already there so it might not actually improve things. [07:43] stub: you're not in the kitchen, btw [07:43] eh? [07:47] #launchpad-kitchen [07:48] Never heard of it [08:08] jtv: thats a nice design, and cool news [08:08] Thank you. [08:21] wgrant: reviewed. Sorry for the slow turnaround [08:22] jtv: there's a kitchen channel on freenode? [08:22] nigelb: no, sorry. Internal. [08:22] Ah, guessed as well :) [08:34] lifeless: Thanks. [08:35] lifeless: I considered removing APAs for public artifacts, but I'm not quite sure how we want to handle policy changes wrt. restricted observers. [08:35] lifeless: eg. if I toggle a bug from private to public and back, does it lose its restricted observers? [08:35] I don't really know yet. [08:38] lifeless: I'd like your opinion about a pattern I've used recently to pre fetch data related to objects in bulk and save quite a few queries. The easy case is when the other data is looked up by primary key, in this case, eager loading stuff and relying on Storm's cache works great. But when the related data is not looked up using a primary key, the only solution I've found is to have a [08:38] cachedproperty and populate it manually. Is this a pattern that you would recommend? I'm asking because I remember Julian saying it was kinda dangerous to have a cachedproperty on a model object… I wonder if all he meant was that you should be careful and call clear_property_cache where it is appropriate or if there was more to it. [08:38] lifeless: here is the branch I'm talking about https://code.launchpad.net/~rvb/launchpad/builders-timeout-bug-887078-eager-load-cachedproperty/+merge/82198 [08:49] wgrant: pick something understandable [08:50] wgrant: e.g. is it less surprising to have unexpected restricted observers, or to lose them when one person does both actions [08:50] rvba: clear_property_cache is done automatically on sqlbase objects [08:50] rvba: see the base class [08:52] rvba: the caches dict comprehension isn't needed, because you only look the caches up just one [08:52] once [08:53] rvba: also on line 56 of the diff you wrap the line, but its < 80 characters all combined [08:54] lifeless: k [08:54] the second eager loading method does use the caches variable [08:54] so I suspect you built one and copied the structure ;) [08:54] true :) [08:55] this looks fine to me [08:55] On line 141 I *had* to call clear_property_cache. [08:55] there used to be a 'do not use cachedproperty on model objects' concept; I removed that edict in my first month as TA - cached property is extremely useful [08:55] rvba: yes, I see that, and its fine [08:55] rvba: (or you could clear just that one cached property, you know :) [08:56] lifeless: right :) [08:56] cachedproperty has the nice properties of being local to the data - not lookaside - and being very visible [08:56] anyhow, +1 on the branch [08:56] thanks, I'll continue working on timeouts! [08:56] it is exactly the sort of move-to-set-based work we need [08:58] There is still room for improvement on https://code.launchpad.net/~user [08:58] induitibly [08:58] https://code.launchpad.net/~lifeless → 113 queries/external actions issued in 4.47 seconds [09:00] I'll get back to that (and to +activereviews) when I'm done with the builder:+history page… [09:03] good morning [09:04] Morning adeuring. [09:04] hi rvba! [09:10] Morning [09:14] Hallo === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugtasks: 277 [10:38] gmb: mvo has put together a branch to be merged in lp yesterday… I asked him to write a MP first, looks like he did it, maybe you can have a look at the branch now if you have some time on your hands? https://code.launchpad.net/~mvo/launchpad/maintenance-check-precise/+merge/82125 [10:39] rvba: Sure, I'll take a look once I'm finished with the current review. [10:39] gmb: thanks. [11:37] morning part people, man you guys don't mess around overnight [11:38] We don't? [11:38] not used to waking to that much email [11:38] heh [11:38] guess it's mainly merge notes [11:38] Yeah, the team should get sub'd to everything. [12:00] I'm suddenly unable to connect to bazaar.launchpad.net [12:01] $ ssh bazaar.launchpad.net [12:01] ssh_exchange_identification: Connection closed by remote host [12:06] jml: I get something different (and more expected?): No shells on this server.\nConnection to bazaar.launchpad.net closed. [12:06] crap [12:06] hmm. I get that now too. [12:07] Internet wind. [12:07] same here. [12:08] ok. just 'wind', as benji says. [12:08] * benji reboots into Windows to edit some video before work. [12:08] ouch [12:10] heh [12:23] Aww, huw isn't here. [12:23] * nigelb will give him a hug tomorrow. [12:23] I just caught up on lp-dev emails. [12:39] oh man, all the good stuff is on that list. Thanks for the heads up nigelb [13:13] jml and benji looks like some peeps in #lp are getting the same issues [13:14] win 40 [13:45] Morning, everyone. [13:46] Hey deryck. [13:46] morning [14:25] rick_h_: :) === mordred_ is now known as mtaylor-xchat [15:01] deryck: I've noticed that if you disable importance and status, their column still takes up space. Had you noticed that? [15:02] abentley, I had yeah. [15:02] deryck: cool. I'll leave it with you. [15:03] abentley, that will likely be the last branch I do this week... a tune up of the page as fields are shown and hidden. [15:03] abentley, or rather, the last branch in the mental list I have of polishing branches :) [15:26] deryck: when the user changes the sorting, but loading the new batch fails, should the sort icon return to its previous value? [15:27] deryck: when the user changes the sorting, but loading the new batch fails, should the sort icon return to its previous value? Should we accomplish this by going "back" in history? [15:27] abentley, hmmmm [15:28] deryck: scratch the second bit. History is updated when we get the new batch. [15:28] abentley, generally, yes, I think the page should not change if the new batch isn't loaded. [15:28] abentley, I don't have a pref about the mechanism we achieve this with. [15:30] deryck: I guess we need a mechanism to sync the batch navigator with the sorting widget in general, so we should use that. [15:30] abentley, right. [15:31] adeuring, I don't think the colors are opacity are quite right on the beta page banner, but I can tune this up this week in a css polish branch. [15:31] s/are/or/ [15:32] deryck: that would be great [15:33] abentley, and FWIW, the form overlay lines up well in FF for me. I'll have to dig deeper what's going wrong for you. [15:33] abentley, maybe the large display you use and overlay scaling? as a guess. [15:34] deryck: width is definitely the issue. [15:34] deryck: i.e. total browser width. [15:34] yeah [15:35] deryck: it starts to happen around 987 pixels wide, and the effect is amplified as the browser gets narrower. [15:39] abentley, ah, ok. Great, thanks. I can repro now. [15:39] deryck: np [15:57] http://code.google.com/p/closure-stylesheets/ I see decorators everywhere [15:59] rvba: ping [16:01] heh, I love that two channels in two networks are discussing the same thing [16:01] rick_h_: pong [16:02] rvba: have a sec to chat/mubmle on proper design implementation to fix https://bugs.launchpad.net/launchpad/+bug/741463 with me? [16:02] <_mup_> Bug #741463: popup diff close button misplaced < https://launchpad.net/bugs/741463 > [16:02] rick_h_: sure, let me have a look at the bug. [16:03] thanks [16:04] nigelb: oh yea? where's the other room? [16:04] rick_h_: #webdev on irc.mozilla.org :) [16:04] rick_h_: (the closure stuff) [16:04] nigelb: ah, gotcha [16:06] rick_h_: is this a chromium specific issue? [16:06] no, I don't believe so [16:06] it's more to do with the content of the popup [16:07] rick_h_: do you have a link to a page with this popup? [16:07] see my comment at the end of the bug [16:07] sure [16:07] https://bugs.launchpad.net/launchpad/+bug/814696 [16:07] <_mup_> Bug #814696: Link to show inline diffs in merge proposals should be green < https://launchpad.net/bugs/814696 > [16:08] click the diff link in my related branch [16:09] ah ok, it the inline diff link… [16:09] right [16:09] that popup has the grey box that most other popups don't have [16:09] so wanted to discuss what's the UI guideline consistant way, add heading text, just pad down, etc [16:10] on a bug, the popup "Subscribe someone else" has the same close button. [16:10] right, but it doesn't have a grey header at the top to cloud up the close button [16:10] true [16:11] jcsackett, do you approve of my running this in the production: https://pastebin.canonical.com/55796/ [16:11] * rvba fires up firebug. [16:12] so we could margin the diff UI to make sure that there's space for the close icon, padd down the diff, or to add some sort of ui component around that close button that keeps it clear [16:12] sinzui: it looks fine to me. [16:13] rick_h_: right now it's positioned using float right and height/margin-top. [16:13] thanks [16:13] rvba: right, but just moving that position won't do it much good [16:14] so for example, jquery ui dialog adds a grab bar/close button combo to prevent the dialog content from interfering: http://jqueryui.com/demos/dialog/ [16:15] for some popups, the large heading does that for us [16:16] I would be in favor of adding a proper heading like we do elsewere. [16:16] ok, I'll start with that path then. [16:16] thanks [16:17] rick_h_: welcome. This is a trivial case because you're just getting started but for more complex case, Huw (huwshimi) is the one to talk to. [16:17] cases even [16:18] ok, deryck gave me a few names and I figured I'd pick randomly to get to introduce myself to everyone [16:18] you got lucky this time :) [16:18] rick_h_: btw, this popup looks completely different in chrome and in firefox. [16:18] rick_h_: that's a good idea to get to "know" the team… [16:19] rvba: yes, FF seems to limit the width unlike chrome [16:19] rick_h_: exactly [16:19] I'll note that as part of this as well [16:19] good. [16:19] this could be a drive-by fix. [16:20] rick_h_: feel free to ping me again or assign me as a reviewer for this once you come up with a MP. [16:20] will do [16:20] rick_h_: but note that I'm Europe so I'll EOD pretty soon ;) [16:21] "*in* Europe" even [16:21] thanks for the heads up [16:21] np [16:31] * jcsacket1 is getting very tired of "run_all" evidently causing kernel panics ... [16:39] c === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 277 [16:51] deryck: could you please run a few SQL queries for me? https://pastebin.canonical.com/55802/ [16:52] adeuring, sure. [16:52] thanks! [16:53] adeuring, you want each one twice? to see if warm cache matters? [16:56] deryck: yes, that would be great [17:01] adeuring, https://pastebin.canonical.com/55803/ [17:01] deryck: thanks! [17:01] adeuring, np! === beuno is now known as beuno-lunch [17:21] deryck: one more SQL query, please: https://pastebin.canonical.com/55805/ (I'd like to know how the new slow distribution related queries compare with "established sorting) [17:23] adeuring, ok === salgado is now known as salgado-lunch [17:27] adeuring, https://pastebin.canonical.com/55806/ [17:27] deryck: great, thanks! [17:29] deryck: so, a similary slow query... I think I'll just ignore the fact that the new queries look a bit quetsionable when run with the ubuntu as the target... [17:30] adeuring, yeah, just get them working, and we can drop or tweak in beta. === Ronnie1 is now known as Ronnie [17:50] deryck: could you review this MP: https://code.launchpad.net/~adeuring/launchpad/bug-sorting-2/+merge/82298 (< 150 lines)? [17:51] adeuring, sure [17:51] deryck: cool, thanks! [17:54] adeuring, looks great. Thanks for removing the need for isinstance! Otherwise, pretty straightforward and r=me. :) [17:54] deryck: thanks :) === jcsackett_ is now known as jcsackett === beuno-lunch is now known as beuno === salgado-lunch is now known as salgado [18:29] I tried to submit the change to increase the per-test yuixhr timeout to avoid occasional spurious failures, but we are already in testfix. Anyone recognize this? https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1557/steps/shell_6/logs/summary [18:30] It looks like a bunch of bzr errors [18:31] gary_poster, saw the exact same errors yesterday. Couldn't repro locally so forced build. [18:32] gary_poster, flacoste suggested disabling the tests if we saw it again. [18:33] deryck, gary_poster: yes, please disable [18:33] deryck, ugh, so yuixhr is not the only culprit. :-( OK, I'll force this build to get my fix in, and then...mm, ok. I wonder if I should disable just the first one as an experiment [18:33] i think we disable codehosting integration tests in the past already [18:33] maybe not those, maybe others [18:33] flacoste, I'm tempted to try disabling only the first one, with the hypothesis that it might be messing up the rest. You fine with that as an experiment? I'll report on it to the list [18:34] gary_poster: sure! [18:34] and welcome back! [18:34] So if it happens again, people can know the experiment fails [18:34] cool [18:34] thanks flacoste :-) === deryck is now known as deryck[lunch] [18:34] and with that, I'll ear :) [18:34] eat, rather. [18:42] gary_poster: chriscoulson is reporting he can't push to bzr on #launchpad [18:43] ssh_exchange_identification: Connection closed by remote host [18:43] gary_poster: can someone on your squad investigate? [18:43] pretty please [18:43] flacoste: i got that a few times trying to bzr branch [18:43] flacoste :-) sure [18:44] he says it started about 30 minutes ago [18:44] bac, are you up for digging into for just a bit? [18:44] I can join you in a few minutes [18:44] flacoste: then after i rechecked the project name it went away. nothing different, just worked later [18:44] if you'd like [18:44] gary_poster: sure [18:44] thank you [18:44] is that the same that was going on this morning? [18:45] we don't know, rick_h. What was going on this morning? :-) [18:45] benji: was looking this morning I think [18:45] bzr issues, then retry would work [18:45] not sure what came of it [18:46] gary_poster, bac, rick_h_: you might want to discuss the details with chriscoulson in #launchpad [18:46] he might confirm it's the same or different problem [18:46] flacoste: actually, gmb and gnuoy were looking at it; restarting the LB made the symtom go away [18:46] yeah, was hoping bac would do that :-) [18:47] I can confirm that I'm seeing the symptom again. [18:47] benji: LB = ? (librarian?) [18:47] load balancer? [18:47] flacoste: load balancer [18:47] load balancer! [18:47] of course [18:47] everyone yell it together: "Load Balancer!" [18:47] lol [18:47] : [18:47] LOAD BALANCER! [18:47] :p === bac changed the topic of #launchpad-dev to: Code hosting is intermittently down. Being investigated. https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 277 === gary_poster changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 277 === deryck[lunch] is now known as deryck [20:14] deryck: there's no OCR. Could you review https://code.launchpad.net/~abentley/launchpad/next-prev/+merge/82308 ? [20:16] abentley, sure. it will be just a minute, though. Finishing something with rick_h_ before he EODs. [20:16] deryck: okay. [20:22] jcsackett, may I have your r for https://pastebin.canonical.com/55809/ [20:23] benji: there is some evidence that bug #808930 is still not fixed [20:23] <_mup_> Bug #808930: Timeout running branch scanner job < https://launchpad.net/bugs/808930 > [20:23] unless we pushed a new bzr version in the last two days [20:23] which i don't remember seeing [20:24] flacoste: good; I was hoping for some good evidence... or that I would never hear of it again ;) [20:24] sinzui: Sure, looks fine to me. Very similar to the last one. [20:25] flacoste: nope, no bzr in the last two days AFAIK; what is the new evidence? [20:25] benji: fair enough :-) i reopened the bug [20:25] Yes, it is. we will not run this until Ian's changes are in production though [20:25] benji: a recent merge proposal that failed [20:25] Ok. [20:26] flacoste: ok; I assume you're putting that in the bug [20:26] benji: i did [20:26] thanks [20:44] abentley, looking at your review... we normally spell those conditionals like: if (Y.Lang.isValue(current_batch.prev)) [20:45] abentley, perhaps this would play better and not force you to specify nulls everywhere in the test? [20:47] deryck: I prefer to be more precise. If current_batch.prev is undefined, that's ill formed data. [20:48] deryck: to me, it's the difference between "I don't know what the next batch is" and "there is no next batch." [20:50] abentley, ah, right. I looked at the check wrong; rather I missed it was a leading to a return. [20:51] abentley, so for consistency I think we should do Y.Lang.isNull(VALUE). but otherwise, it looks good. [20:51] I realize the === is standard language stuff, but we've been driving people to use the isXXX wrappers for awhile now. [20:52] deryck: what's the advantage of the isXXX wrappers? [20:52] abentley, for this sort of thing, not much. the isValue is simpler to right than 3 or 4 checks against non-valuey values.... [20:53] abentley, I think the argument is just to be consistent using Y.Lang. [20:53] deryck: Yes, I agree about isValue. Very handy. [20:53] above I meant write, not right. sorry. [20:54] abentley, I think isNull is nice too that you don't accidentally write ==, but lint should catch that. [20:54] deryck: that's true. [20:55] abentley, plus if we're consistent about it, it makes it easier on devs looking at js code. no misreading or mis-cut-n-pasting. :) [20:57] abentley, also, this is in our style guide under "Plain Old JavaScript." Not that we follow that wonderfully, but it was thought through at some point. [20:57] deryck: Okay. I certainly missed that. [20:57] sinzui: I'm thinking about getting rid of the DistributionSourcePackage/DistributionSourcePackageInDatabase split. Have you ever given this thought before? I'm trying to see if I can steal someone else's plan. [20:59] abentley, r=me with that minor change. [21:00] deryck: thanks. [21:00] np! [21:01] I think gmb has the new all-time best term for our meetings: Thunderepic! [21:10] heh. found === checks in my own code. hard to get in that habit. [21:15] abentley, care to return the favor? I need a review too. [21:15] deryck: sure. [21:15] abentley, thanks! https://code.launchpad.net/~deryck/launchpad/field-visibility-dry/+merge/82316 [21:16] allenap: purple think this can happen. We were going to do it, but we ran out of time. Our remaining concern are cases where Lp works with a virtual DSP before creating the real thing [21:18] sinzui: Okay, that sounds doable. I don't really have any more questions yet, but at least I know it's not a fool's errand. Thanks. [21:34] deryck: I'm not sure it's a good idea for us to maintain both LP.cache.field_visibility and ListingNavigator.field_visibility as models of field visibility. [21:35] abentley, ok. do you mean BugListingConfigUtil.field_visibility rather than ListingNavigator? [21:36] I mean ListingNavigator. I don't know about BugListingConfigUtil.field_visibility. [21:36] But if you mean that there are actually three models of field visibility, then I think we definitely need to reconsider. [21:37] abentley, well BugListingConfigUtil keeps a reference internally, but uses the cache as the model or definitive source. [21:37] abentley, but I was tossed up about keeping the reference around even, so don't mind dropping it if you think so. [21:38] deryck: I see. === dames is now known as thedac [21:39] abentley, is your earlier question about something I've done in this code? Or a general question about field_visibility in ListingNavigator? [21:39] deryck: Yes, it's about you wanting to update LP.cache in case other folks are using it. [21:40] deryck: that means it's a model of some of the page state. [21:41] abentley, ah ok. [21:41] abentley, I see what you mean now. My understanding was that was what we were using. if it's only effort for default page load values, then I can drop that bit. [21:42] deryck: I'm using the wrap_resource version of the cache, so it should be a separate copy. [21:42] deryck: if it isn't, then you're changing LN's internal state, and LN [21:43] deryck: is changing BLCU's internal state. [21:44] abentley, gotcha. yeah, I'll drop that then and only pass off to LN the way we currently do. [21:45] StevenK: oh hi mr OCR [21:45] https://code.launchpad.net/~lifeless/python-oops-wsgi/bug-888866/+merge/82088 [21:45] deryck: I tend to think the BLCU and LN should explicitly share a model. [21:48] abentley, perhaps. I don't mind doing the event-based hand off right now, until we see it becomes an issue. [21:49] deryck: Actually, the status widget needs to share that model, too. [21:49] deryck: since only visible fields should be sortable. [21:49] StevenK: and https://code.launchpad.net/~lifeless/python-oops-datedir-repo/oops-prune/+merge/82324 [21:49] abentley, ah, right. [21:49] StevenK: please :) [21:50] abentley, I was going to do an event thing again. [21:50] abentley, but it would be nice if the events could fire and each piece look into the model for state. where the model is independent of our widgets. [21:51] deryck: Yes, I think that would be nice, too. [21:52] abentley, do you mind this branch as it, and let me press ahead with some polish and we can discuss this issue early tomorrow? [21:52] deryck: sure. [21:53] abentley, awesome, thanks! [21:54] deryck: why does the valueFn for field_visibility_defaults check LP.cache.field_visibility? [21:54] hi all [21:55] abentley, I was routing everything through field_visibility in the cache. This is the part I'll change I'll change per this discussion. [21:55] hi poolie [21:56] deryck: but why doesn't it check LP.cache.field_visibility_defaults? [21:57] abentley, ah, sorry. That's a bug. I misread your question. [21:57] abentley, I can't believe the test didn't catch it. That's scary. [21:57] deryck: hehe. [21:58] abentley, ah, I see it's just the existence check, not the value. and since both are found in the test setup. [21:58] abentley, I'll do a little wrapper method for "does the cache exist and have these values" to prevent this goof again. [21:59] deryck: okie. [22:00] deryck: r=me with that bugfix. [22:01] abentley, awesome sauce. Thanks! [22:02] so what does r=me stand for? I've not been able to figure that shortcut out [22:02] rick_h_, in the commite message the tools we use to land add r=ircnick for who approved the branch. [22:03] rick_h_, so it's shorthand for r=deryck or "you have an approval vote from me" [22:03] ah, ok so less a shortcut and more a reference [22:03] rick_h_, exactly. [22:04] ok, until tomorrow then. later all! [22:07] sinzui: in an ongoing saga of useless technology, i cannot seem to connect to mumble. [22:09] jcsackett, :( Do you have a message for us on IRC about loggerhead and or team branches [22:10] sinzui: loggerhead branch should be out in the wild soon. i've been battling a kernel panic whenever i try to run codehosting stuff, but think i have that resolved. i intend to work longer today to catch up, because i'm irritated. [22:11] sinzui: finally found bug 813146, which includes stuff to deal with it, so trying that. [22:11] <_mup_> Bug #813146: kernel panic when running Python test suite on ecryptfs <3.0.0-11.18> sinzui: it's not been a good day. :-P [22:11] (thus saga of useless technology). [22:12] sinzui, wgrant, wallyworld: http://pastebin.ubuntu.com/739703/ [22:58] StevenK: hi [22:59] lifeless: Distracted by e-mail and breakfast [23:08] lifeless: Approverated with a small comment. [23:09] both ? [23:10] StevenK: ^ [23:20] lifeless: person merge and fastdowntime [23:20] Any suggestions? [23:21] fire and brimstone ? [23:21] Since it checks for foreign keys. [23:21] So if I add a new column referencing person, person merge breaks. [23:21] yeah [23:21] don't add the reference [23:21] Two-step schema patch, or a whitelist of empty tables? [23:22] Mmm. [23:22] That seems bad. [23:22] But maybe,. [23:22] aka two step schema patch [23:22] add the column [23:22] update person merge [23:22] I know [23:22] make it a reference [23:22] start using it [23:22] But two-step schema patches for everything seems bad. [23:22] less bad than 1 hour downtimes, and currently I think its an either-or choice [23:23] Well, I'd prefer two-step code patches. [23:23] if that works, I'm fine with it [23:42] lifeless: There was a second one? [23:42] 10:45 < lifeless> StevenK: oh hi mr OCR [23:42] 10:45 < lifeless> https://code.launchpad.net/~lifeless/python-oops-wsgi/bug-888866/+merge/82088 [23:43] if you'd be so kind [23:44] lifeless: Aren't you, you know, supposed to not be working today? [23:45] StevenK: yesterday was a write-off [23:45] so its a bit backwards. [23:45] wallyworld: launchpad.See? Really? [23:46] StevenK: sinzui said it had to be a verb, and i thought something analogous to View. any better suggestions welcome [23:46] i originally had launchpad.Exists [23:47] Exists is a verb [23:47] i guess so. i'll have to check the email to see why that was not preferred [23:47] i prefer Exists [23:47] benefits of learning french :) [23:48] etre [23:49] wallyworld: And why can't we use lp.View? [23:49] lifeless: Exists is a verb but not a transitive one like View or Moderate [23:50] StevenK: because we want something that is less than View [23:50] ie they can only see the basic details [23:50] of a private artifact by virtue of the fact they can see an associated object [23:51] They're not all verbs. [23:51] eg. launchpad.BugSupervisor, launchpad.Driver, zope.Public... [23:51] Personally, I remain unconvinced. [23:51] sure, but the preference for verbs was indicated [23:52] i'm happy to change it to Exists or something better [23:52] whatever the consensus is [23:52] I think my issue is adding a new permission. [23:53] We need a new permission. [23:53] (or to abolish permission, but that's a story for another day) [23:53] so I think the idea behind verb is to be able to say 'user can ' [23:53] which clearly zope.Public doesn't fit. [23:53] and the others wgrant mentioned. [23:53] In which lp.See makes more sense [23:54] I think exists is ambiguous and confusing on that basis. [23:54] Observe ? [23:54] TellExists [23:54] the key thing to hint at is that they only get shallow metadata [23:54] You can observe the object, but you can't view it in the 'user can ' [23:55] you could, for instance, grant zope.Public on private objects when the user can see their existence. [23:55] i like Observe [23:55] This would be appropriate. [23:55] Although Observe already has an alternate meaning in Disclosure. [23:55] It means "see absolutely everything" [23:55] right, using observe would be horribly confusing. [23:55] lp.C [23:55] tell me, why is this a new permission vs refined granting of existing permission [23:55] we could redefine observer in disclosure :-P [23:56] What could possibly go wrong [23:56] we didn't want to change what View meant [23:56] is it because the existing permissions grant access to the whole object, so we've got no middle ground to work with [23:56] yes [23:56] yeah, fair enough [23:56] so [23:56] RestrictedView [23:56] is my suggestion [23:56] that works [23:56] or LimitedView [23:57] i guess Exists was used because it more closer defines what semantics were are trying to implement [23:57] ie can the user know of the existance of this private artifact [23:57] KnowExists [23:57] that works too [23:58] i think any choice will not be "perfect" [23:58] If I was doing this, i think I would use KnowExists, or LimitedView [23:59] LimitedView is nice because it modifies an existing permission which people understand. well that appeals to me anyway