[00:46] <flacoste> lifeless: o/
[02:53] <StevenK> wallyworld: Your rev is qa-bad. It doesn't work, but it doesn't hurt either.
[02:55] <lifeless> StevenK: isn't that qa-ok
[02:55] <StevenK> Well, I'll be marking it as such
[02:56] <StevenK> We need a tag for failed QA but safe to deploy
[02:56] <wgrant> StevenK: That's qa-ok
[02:56] <wgrant> qa-FOO refers to deployment safety
[02:56] <wgrant> Nothing about functionality of the change itself
[09:11] <adeuring> good morning
[09:12] <czajkowski> morning
[09:20] <czajkowski> 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 <loggerhead:New> < https://launchpad.net/bugs/1075907 >
[09:28] <mgz> czajkowski: not really.
[10:05] <czajkowski> mgz: nobody seems to be :(
[11:33] <rick_h> 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] <rick_h> czajkowski: but no idea tbh as to the fix
[11:33] <rick_h> 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] <czajkowski> rick_h: ahhh
[11:36] <czajkowski> thank you
[13:45] <jcsackett> morning, all.
[14:02] <rick_h> morning jcsackett
[14:04] <bac> hi jcsackett
[14:58] <rick_h> 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 <javascript> <ui> <ui-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1076540 >
[14:59] <deryck> rick_h, fine with me.  just meant to capture the idea, so it works for that.
[14:59] <abentley> rick_h: +1.
[15:00] <abentley> rick_h: Just had a thought that maybe we could add that functionality to the base template, instead.
[15:00] <rick_h> abentley: ah ok, and do a conditional if the attribute is defined add the YUI block?
[15:00] <abentley> rick_h: Right.
[15:01] <abentley> rick_h: For ultra-mega-consistency.
[15:01] <rick_h> abentley: yea, that makes sense and makes for even less new code/changes
[15:01] <rick_h> noted in a follow up comment
[16:52] <abentley> bac: Could you please review https://code.launchpad.net/~abentley/lp-dev-utils/cs-test/+merge/133712 ?
[16:54] <bac> abentley: i'll be glad too after this meeting and lunch
[16:54] <abentley> bac: Thanks.
[16:56] <sinzui> bac, do you have time to review https://code.launchpad.net/~sinzui/launchpad/poimport-typeerror/+merge/133713
[16:56] <bac> sinzui: i'll be glad too after this meeting and lunch
[16:56] <bac> s/too/to
[16:56] <sinzui> thank you
[17:49] <bac> abentley: how long do these tests take on canonistack?
[18:03] <sinzui> enail?
[18:03] <sinzui> thanka bac
[18:03] <sinzui> I think I want enails. With programmable nails I could change the colour or pattern in seconds
[18:09] <jcsackett> sinzui: ooh! you could have fractals at that point. :-P
[18:16] <abentley> bac: ~391 minutes.
[18:17] <abentley> so 6:31
[18:18] <bac> speedy
[18:19] <bac> 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] <abentley> Well, the whole install takes about 10 minutes.
[18:20] <abentley> So it's not a big percentage, so far.
[18:21] <abentley> But m1.small are multi-core, so parallel-testing should be possible in theory.
[18:23] <abentley> Using a larger instance type would also help.
[18:25] <bac> abentley: i guess since we're in the data center the fetch of the branch is fast
[18:25] <abentley> bac: I checkout, rather than fetch the branch, so it's just creating the working tree.  It's about a minute.
[18:27] <bac> abentley: are you providing instructions for use anywhere?  perhaps with reference to canonistack setup page.
[18:27] <abentley> bac: I just wanted to get the code out there, to start, so that we can iterate on it.
[18:28] <bac> abentley: ok.
[18:29] <bac> abentley: done
[18:29] <bac> thanks
[18:30] <abentley> bac: Thanks you!
[18:31] <abentley> bac: Could you please review https://code.launchpad.net/~abentley/launchpad/optimize-spec-query/+merge/133716 ?
[18:41] <abentley> 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] <bac> abentley: ok.  then please DO NOT remove it after QA.  :)
[18:42] <bac> sorry for the misread
[18:42] <abentley> bac: roger.
[18:42] <abentley> bac: Thanks for the review.
[19:10] <rick_h> 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] <jcsackett> rick_h, sinzui: i can take it, as long as about 30 min delay is alright.
[19:11] <rick_h> yea definitely. No rush.
[19:11] <rick_h> thanks jcsackett
[19:11] <jcsackett> cool.
[19:13] <sinzui> 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] <rick_h> sinzui: <3 on all accounts
[19:48] <jcsackett> 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] <rick_h> jcsackett: no, it doesn't currently render w/o JS
[19:49] <rick_h> 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] <jcsackett> 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] <rick_h> k, thinking of how to try to incorperate that without duplicating the html template and such in multiple places
[19:52] <rick_h> and ugh :P
[19:52] <jcsackett> sinzui: do we still have a limited case for needing the banner on no-js browsers?
[19:52] <jcsackett> rick_h: i'm sorry i didn't notice this in your last sanity check--i wasn't thinking then. :-/
[19:52] <sinzui> YES
[19:52] <jcsackett> that was emphatic. :-p
[19:52] <sinzui> LTS headless requires it
[19:53] <rick_h> 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] <abentley> rick_h: You could use mustache-- I added it specifically so we could use the same template for HTML and js.
[19:53] <rick_h> sinzui: LTS headless?
[19:53] <rick_h> abentley: yea, the tempalte was small enough I didn't use mustache so will look that route perhaps
[19:53] <jcsackett> 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] <rick_h> but you still end up with collisions of message text generatoin and such
[19:53] <jcsackett> sinzui, that sound right? ^
[19:54] <rick_h> jcsackett: yea, that makes sense. I noticed they have more vague default messages
[19:54] <sinzui> 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] <rick_h> but yea, didn't think banners were in any way functional and required to work non-js
[19:54] <jcsackett> rick_h: yeah, the "stuff here is hidden, somehow".
[19:54] <jcsackett> i *think* the boring html version is already there; you may be fine.
[19:55] <jcsackett> at least this branch may be--the wiring just needs to not kill it.
[19:55] <rick_h> jcsackett: well I rip it out in order to remove duplication and making it easier to edit/adjust
[19:55] <rick_h> jcsackett: so yea, it's something I'll have to hea back with and think on for a minute
[19:55] <jcsackett> 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] <jcsackett> *this* branch though i don't believe is impacted.
[19:56] <rick_h> jcsackett: true, this branch is totally unconnected atm
[19:56] <jcsackett> again: i'm sorry i didn't notice this when i last looked.
[19:56] <rick_h> but if I move to mustache then the generation here will alter
[19:56] <rick_h> though not in any killer way
[19:58] <jcsackett> 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] <jcsackett> so r=me on the first one.
[19:59] <rick_h> jcsackett: ok, thanks
[19:59] <jcsackett> rick_h: no problem.
[20:23] <abentley> 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 <private-projects> <Launchpad itself:In Progress by abentley> < https://launchpad.net/bugs/1076412 >
[20:24] <deryck> 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] <abentley> 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] <abentley> deryck: So Embargoed product with proprietary bugs is okay, and vice versa.
[20:26] <abentley> Right?
[20:26] <deryck> abentley, right.
[20:27] <abentley> deryck: Great.