[00:46] lifeless: o/ [02:53] wallyworld: Your rev is qa-bad. It doesn't work, but it doesn't hurt either. [02:55] StevenK: isn't that qa-ok [02:55] Well, I'll be marking it as such [02:56] We need a tag for failed QA but safe to deploy [02:56] StevenK: That's qa-ok [02:56] qa-FOO refers to deployment safety [02:56] Nothing about functionality of the change itself [09:11] good morning [09:12] morning [09:20] Does anyonek know anything about loggerhead bugs ? https://bugs.launchpad.net/loggerhead/+bug/1075907 [09:20] <_mup_> Bug #1075907: Loggerhead - serving two directories from parent < https://launchpad.net/bugs/1075907 > [09:28] czajkowski: not really. [10:05] mgz: nobody seems to be :( [11:33] czajkowski: so I'll confirm the bug as abently and I hit it when working on helping the guy with loggerhead JS stuff back on wed [11:33] czajkowski: but no idea tbh as to the fix [11:33] czajkowski: I can say the whole profile thing is just a side show. It's a tool to help debug performance and it's not that, just isn't working atm [11:36] rick_h: ahhh [11:36] thank you === dimitern is now known as dimitern_lunch === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === dimitern_lunch is now known as dimitern [13:45] morning, all. [14:02] morning jcsackett === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On Call Reviewer: bac | Firefighting: - | Critical bugs: ~200 [14:04] hi jcsackett [14:58] deryck: abentley just want to make sure this encapsulates/makes sense to others https://bugs.launchpad.net/launchpad/+bug/1076540/comments/1 [14:58] <_mup_> Bug #1076540: branch +edit doesn't load picker JS for pretty UI elements

< https://launchpad.net/bugs/1076540 > [14:59] rick_h, fine with me. just meant to capture the idea, so it works for that. [14:59] rick_h: +1. [15:00] rick_h: Just had a thought that maybe we could add that functionality to the base template, instead. [15:00] abentley: ah ok, and do a conditional if the attribute is defined add the YUI block? [15:00] rick_h: Right. [15:01] rick_h: For ultra-mega-consistency. [15:01] abentley: yea, that makes sense and makes for even less new code/changes [15:01] noted in a follow up comment === matsubara is now known as matsubara-lunch [16:52] bac: Could you please review https://code.launchpad.net/~abentley/lp-dev-utils/cs-test/+merge/133712 ? [16:54] abentley: i'll be glad too after this meeting and lunch [16:54] bac: Thanks. [16:56] bac, do you have time to review https://code.launchpad.net/~sinzui/launchpad/poimport-typeerror/+merge/133713 [16:56] sinzui: i'll be glad too after this meeting and lunch [16:56] s/too/to [16:56] thank you === matsubara-lunch is now known as matsubara === gary_poster|away is now known as gary_poster === gary_poster is now known as gary_poster|away === gary_poster|away is now known as gary_poster === gary_poster|away is now known as gary_poster === deryck is now known as deryck[lunch] [17:49] abentley: how long do these tests take on canonistack? [18:03] enail? [18:03] thanka bac [18:03] I think I want enails. With programmable nails I could change the colour or pattern in seconds [18:09] sinzui: ooh! you could have fractals at that point. :-P [18:16] bac: ~391 minutes. [18:17] so 6:31 [18:18] speedy [18:19] abentley: i guess lpsetup takes a long time too since it has to fetch the whole lp branch. ie it isn't preseeded in the ami like our ec2 runs, correct [18:20] Well, the whole install takes about 10 minutes. [18:20] So it's not a big percentage, so far. [18:21] But m1.small are multi-core, so parallel-testing should be possible in theory. [18:23] Using a larger instance type would also help. [18:25] abentley: i guess since we're in the data center the fetch of the branch is fast [18:25] bac: I checkout, rather than fetch the branch, so it's just creating the working tree. It's about a minute. [18:27] abentley: are you providing instructions for use anywhere? perhaps with reference to canonistack setup page. [18:27] bac: I just wanted to get the code out there, to start, so that we can iterate on it. === Ursinha_ is now known as Ursinha [18:28] abentley: ok. [18:29] abentley: done [18:29] thanks [18:30] bac: Thanks you! [18:31] bac: Could you please review https://code.launchpad.net/~abentley/launchpad/optimize-spec-query/+merge/133716 ? [18:41] bac: The code isn't actually obsolete yet. I haven't moved every get_specification_privacy_filter call over to visible_specification_query yet. [18:41] abentley: ok. then please DO NOT remove it after QA. :) [18:42] sorry for the misread [18:42] bac: roger. [18:42] bac: Thanks for the review. === deryck[lunch] is now known as deryck === yofel_ is now known as yofel [19:10] jcsackett: or sinzui I've got a series of very JS branches coming for the updated banner work and would love to get some more UI special reviews for these if you don't mind. https://code.launchpad.net/~rharding/launchpad/add_new_banner/+merge/133736 is the first branch that adds the new code [19:10] rick_h, sinzui: i can take it, as long as about 30 min delay is alright. [19:11] yea definitely. No rush. [19:11] thanks jcsackett [19:11] cool. [19:13] rick_h, I think you would enjoy this when you get a break. It's David Mitchells rant on modern furniture: http://www.youtube.com/watch?v=syii9DKnb2M [19:31] sinzui: <3 on all accounts [19:48] rick_h: is this still going to work with the static html version for no javascript browsers? To my knowledge we still have to support that case. [19:49] jcsackett: no, it doesn't currently render w/o JS [19:49] jcsackett: didn't realize that was a requirement for the banner since it would fail to work on the informatino type change w/o JS [19:51] rick_h: yeah, we accepted just at least having the banner on reload, since no one expects on the fly change when there's no JS. [19:52] k, thinking of how to try to incorperate that without duplicating the html template and such in multiple places [19:52] and ugh :P [19:52] sinzui: do we still have a limited case for needing the banner on no-js browsers? [19:52] rick_h: i'm sorry i didn't notice this in your last sanity check--i wasn't thinking then. :-/ [19:52] YES [19:52] that was emphatic. :-p [19:52] LTS headless requires it [19:53] heh, so that corrects my misconception that there was a limited set of features for non-js such as filing a bug and such which banners wouldn't get involved with [19:53] rick_h: You could use mustache-- I added it specifically so we could use the same template for HTML and js. [19:53] sinzui: LTS headless? [19:53] abentley: yea, the tempalte was small enough I didn't use mustache so will look that route perhaps [19:53] rick_h: the banners don't need to do hot updates or even be totally accurate to infotype. i think a banner of "information on this page is restricted by info type" that never changes or the like satisfies the need. [19:53] but you still end up with collisions of message text generatoin and such [19:53] sinzui, that sound right? ^ [19:54] jcsackett: yea, that makes sense. I noticed they have more vague default messages [19:54] precise will live for years with old browsers, and browsers from servers that need to do a confidential actions need to know the action is trusted [19:54] but yea, didn't think banners were in any way functional and required to work non-js [19:54] rick_h: yeah, the "stuff here is hidden, somehow". [19:54] i *think* the boring html version is already there; you may be fine. [19:55] at least this branch may be--the wiring just needs to not kill it. [19:55] jcsackett: well I rip it out in order to remove duplication and making it easier to edit/adjust [19:55] jcsackett: so yea, it's something I'll have to hea back with and think on for a minute [19:55] rick_h: right, i think you can not rip it out and make sure the banners use the built in HTML_PREPROCESSOR so your other stuff works. [19:55] *this* branch though i don't believe is impacted. [19:56] jcsackett: true, this branch is totally unconnected atm [19:56] again: i'm sorry i didn't notice this when i last looked. [19:56] but if I move to mustache then the generation here will alter [19:56] though not in any killer way [19:58] rick_h: i'm approving this branch, at least. you may need to do further changes against it in wiring, but the new modules are all good. [19:58] so r=me on the first one. [19:59] jcsackett: ok, thanks [19:59] rick_h: no problem. === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On Call Reviewer: - | Firefighting: - | Critical bugs: ~200 [20:23] deryck: starting to work on bug #1076412. Quick pre-imp? [20:23] <_mup_> Bug #1076412: Proprietary projects should only allow proprietary policies on its artifacts < https://launchpad.net/bugs/1076412 > [20:24] abentley, I have a couple things I'm trying to finish before EOD. Wanna wait until Monday? Or maybe chat with rick_h about it? [20:25] deryck: The basic thing is we're going to draw a line between Poprietary and Embargoed and Public types, WRT sharing and product info type. [20:26] deryck: So Embargoed product with proprietary bugs is okay, and vice versa. [20:26] Right? [20:26] abentley, right. [20:27] deryck: Great.