[00:00] <huwshimi> lifeless: On #712894 you mentioned some helpers to preload user's avatars. Are there any docs on how to use that or can you explain where I might start?
[00:00] <_mup_> Bug #712894: Display avatars next to usernames instead of icons <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/712894 >
[00:01] <lifeless> getUtility(IPersonSet).cacheBrandingForPeople(participants)
[00:01] <lifeless> see model/person.py for the gory details
[00:01] <huwshimi> lifeless: Thanks mate
[00:04] <cjohnston> is there any plan on setting up LP to be translated?
[00:05] <huwshimi> lifeless: Do I need to use that once on all the users that need an avatar on the page, or can I call it whenever I want (note, this is an exercise in me learning the codebase, so I might be asking dumb questions)?
[00:06] <lifeless> cjohnston: there was discussion @ UDS, met favourably, to do so. But its not scheduled.
[00:06] <lifeless> huwshimi: that should (I haven't checked that its correct :P) be called once on a page, because doing one person at a time would be terribly slow.
[00:06] <cjohnston> im guessing alot of work involved?
[00:07] <huwshimi> lifeless: Ok thanks, I'll look into it a bit more... might not be feasible to do that then.
[00:08] <lifeless> huwshimi: it is going to need to be called once, for *every page* that starts showing avatars
[00:08] <lifeless> huwshimi: or performance will go to the toilet.
[00:08] <huwshimi> lifeless: Yeah, that is going to be a big issue
[00:09] <Ronnie> how is https://login.ubuntu.com/ connected to https://login.launchpad.net/
[00:09] <wgrant> Ronnie: They are just alternative skins for the same service.
[00:10] <wgrant> Same DB.
[00:10] <spm> same servers even
[00:10] <wgrant> The latter will hopefully go away eventually.
[00:10] <lifeless> huwshimi: its going to need extreme care
[00:10] <wgrant> Ubuntu services should prefer the forer.
[00:10] <wgrant> +m
[00:10] <lifeless> cjohnston: a moderate amount of work
[00:11] <cjohnston> If you create a login.u.c you dont have an LP account though correct?
[00:11] <Ronnie> wgrant: so when you register on ubuntu.com you can login to LP?
[00:11] <wgrant> Ronnie, cjohnston: You don't automatically have an LP account if you create an account on either.
[00:12] <wgrant> But if you try to log into Launchpad, it will redirect you to login.launchpad.net. You can then log in using your login.ubuntu.com account, and Launchpad will create an account for you.
[00:12] <wgrant> LP is an OpenID consumer, just like LD.
[00:12] <wgrant> (except that login.ubuntu.com and login.launchpad.net use a private interface to return data from the linked LP account, if it exists)
[00:12] <cjohnston> wgrant: the reason for the questions is that people are wanting to move away from the LP requirement for LP.. but the devs dont really see it as possible
[00:13] <lifeless> cjohnston: the which requirement for LP ?
[00:13] <cjohnston> lifeless: you must have an LP account to be a part of a team, and to register for an event/meeting
[00:13] <lifeless> cjohnston: you said 'LP requirement for LP'
[00:13] <lifeless> cjohnston: this confused me
[00:14] <cjohnston> People don't like sorry
[00:14] <cjohnston> LP requirement for LD
[00:14] <lifeless> ok
[00:14] <lifeless> right, with that cleared up
[00:14] <thumper> why do I often feel like I'm the first person to do something :-(
[00:14] <lifeless> LP maintains the team database
[00:14] <thumper> writing lazr-js tests
[00:14] <cjohnston> correct
[00:15] <lifeless> so I don't think you're going to get away from that at all easily; and there are no plans to make SSO maintain teams
[00:15] <cjohnston> People 1) dont like the fact that they have to sign up somewhere other than LD... and 2) that LP isnt translated
[00:15] <cjohnston> right
[00:15] <lifeless> (SSO teams are mirrored from LP)
[00:15] <cjohnston> lifeless: thats what the couple devs have a hard time explaining to people
[00:15] <lifeless> we'd take patches for I18N of LP
[00:15] <cjohnston> I bet
[00:15] <cjohnston> heh
[00:16] <lifeless> at one point we wouldn't have.
[00:16] <lifeless> but I think that that bridge has been successfully fixed.
[00:16] <wgrant> Excellent.
[00:17] <Ronnie> cjohnston: can we set login.ubuntu.com as openid provider?
[00:17] <Ronnie> i tested locally and worked fine with login
[00:18] <wgrant> For a while it wasn't open to arbitrary consumers, but I think that changed a few months ago.
[00:18] <Ronnie> hmm, but for joining a team, we still need to login to LP
[00:18] <cjohnston> users still need lp accounts to make LD useful...
[00:18] <lifeless> Ronnie: login.ubuntu.com is fine.
[00:19] <Ronnie> cjohnston: they need to login only once to LP to join the team, but for other parts the l.u.c. should be fine (altough the mugshot is also in LP)
[00:20] <cjohnston> correct.. so why not just leave it the way it is since they still have to go into lp?
[00:21] <Ronnie> lifeless, wgrant: is there an alternative way to join a lp team, than the webpage?
[00:21] <lifeless> Ronnie: apis, but the user still has to accept the membership
[00:21] <wgrant> lifeless: No, they don't :(
[00:21] <lifeless> and you can't talk about a user until they sign into LP once.
[00:21] <wgrant> Right.
[00:22] <wgrant> The LD can add people to teams.
[00:22] <lifeless> wgrant: as part of the disclosure work that should be fixed
[00:22] <wgrant> But they need to have an LP account first.
[00:22] <wgrant> And there's no way to create one of those unless the user logs in.
[00:22] <wgrant> Or you are the Software Center Agent (ugh)
[00:23] <Ronnie> wgrant: is it possible to do one login to LP in the background, so the user is not aware (or manually restyle the page somehow?)
[00:24] <Ronnie> lifeless: and how should the user accept the membershit trough api?
[00:24] <wgrant> That would be very bad.
[00:25] <Ronnie> making programms userfriendly, is sometimes choosing between 'the bad stuff' of the 'hard stuff' ;)
[00:25] <Ronnie> of = or
[00:26] <lifeless> Ronnie: they would get an email with a link to click on
[00:26] <lifeless> os
[00:26] <lifeless> so
[00:26] <lifeless> what teams does LD care about?
[00:26] <Ronnie> all the team which are subteams of the main loco team (cant remember the name)
[00:27] <cjohnston> ubuntu-locoteams iirc
[00:27] <Ronnie> https://launchpad.net/~locoteams
[00:27] <lifeless> anyhow, I don't see - in principle - a problem with designing and building a facility for LD and other closely affiliated sites to have impersonation facilities for users.
[00:27] <lifeless> whether that looks like LP APIs or something radically different is an open question.
[00:27] <cjohnston> but we also have a plan of adding a "sister" to LD being a global directory which will provide the meeting feature (and upcoming team reports) to all teams that want it
[00:28] <lifeless> the SCA approach seems rather unscalable from a risk perspective to me.
[00:28] <Ronnie> SCA?
[00:28] <lifeless> software centre agent
[00:29] <Ronnie> lifeless: so having an API for 'trusted affilated'  sites is an option?
[00:30] <lifeless> yes
[00:30] <lifeless> I've spent approx 0 time thinking about the necessary requirements and constraints for it though.
[00:30] <Ronnie> cjohnston: i think thats a very good solution
[00:31] <cjohnston> Except for what lifeless just siad
[00:31] <cjohnston> said
[00:31] <Ronnie> indeed
[00:32] <Ronnie> lifeless: and the 'one time lp login' can that be solved by the same API (in your first toughts)
[00:32] <lifeless> Ronnie: if LD was able to act as an LP frontend
[00:32] <lifeless> Ronnie: then it could create accounts given an sso signed in user, add them to teams etc
[00:33] <Ronnie> but is haveing LD as a frontend not very dangerous without limiting the features?
[00:34] <lifeless> Ronnie: thats right, thus - 13:30 < lifeless> I've spent approx 0 time thinking about the necessary requirements and constraints for it though.
[00:34] <lifeless> we'd be separating the business logic from presentation
[00:34] <lifeless> and we'd need an impersonation api for the glue
[00:35] <lifeless> so you could say 'on behalf of <ld logged in user> create a LP account'
[00:35] <lifeless> but the integrity of the system would be maintained by the LP middleware
[00:38] <Ronnie> i have to sleep and think about it for a while. i added this channel for auto join
[00:38] <lifeless> cool
[00:38] <Ronnie> till soon
[00:38] <thumper> huwshimi: ping
[00:39] <huwshimi> thumper: Hello
[00:39] <thumper> huwshimi: do you know how to get some javascript to drop into the firebug debugger?
[00:39] <thumper> huwshimi: I think it is something like " Y.debug() "
[00:39] <wgrant> Ronnie: But we cannot sacrifice security like that for user friendliness.
[00:39] <wgrant> Except perhaps as lifeless suggests.
[00:40] <huwshimi> thumper: console.log();
[00:40] <wgrant> In a very restricted context.
[00:40] <huwshimi> thumper: That will work on Chrome debugger too
[00:40] <thumper> huwshimi: I don't want to log stuff out, I want to debug some javascript
[00:41] <huwshimi> thumper: What kind of info do you want?
[00:41] <thumper> I want to interrogate the DOM state mid function call
[00:41] <thumper> I'm not sure if my test is wrong, or the code isn't doing what it says it should
[00:41] <thumper> I'm trying to add a test for the multi line lazr-js editor
[00:42] <huwshimi> thumper: There is console.debug, but I can't remember what it does
[00:42] <thumper> huwshimi: ok, ta
[00:43] <huwshimi> thumper: Check out this page: http://getfirebug.com/logging
[00:43] <huwshimi> thumper: It has info about stack traces etc.
[00:43] <huwshimi> thumper: From memory if you log a reference to a function you can get a whole pile of info from it
[00:46] <huwshimi> thumper: So if you do a console.log(YAHOO.util.Dom) or whatever it should give you an object with a bunch of properties
[00:49] <huwshimi> thumper: Just ducking out for a minute. Let me know if that doesn't help you and I'll get to it when I'm back
[00:49] <lifeless> wallyworld_: can I have a review please of https://code.launchpad.net/~lifeless/launchpad/bug-661988/+merge/48740 ?
[00:49]  * wallyworld_ looks
[00:50] <thumper> huwshimi: ack
[01:02] <wallyworld_> lifeless: is this an r-c for 11.02?
[01:03] <lifeless> wallyworld_: no
[01:03] <lifeless> wallyworld_: it will halve the time taken to do distribution bug searches
[01:03] <lifeless> wallyworld_: which is a nice improvement, and will drop a top 10 timeout out of the list
[01:04] <wallyworld_> lifeless: sure. a question - why is product_ids.discard(None) needed?
[01:04] <lifeless> wallyworld_: that should be obvious :)
[01:04] <lifeless> wallyworld_: there are multiple different contexts a task can be target to.
[01:05] <wallyworld_> ah, ok.
[01:05] <wallyworld_> and we were using a left join
[01:05] <wallyworld_> previously
[01:05] <lifeless> the left join was crack and is unrelated
[01:05] <wallyworld_> osrry for the dumb question
[01:05] <lifeless> bug:bugtask is 1:M
[01:06] <lifeless> bugtask.bug is never NULL
[01:06] <lifeless> and bugs always have one or more bugtasks.
[01:07] <lifeless> wallyworld_: the linked bugs in the mp explain it all
[01:07] <wallyworld_> and the list(store.find(..)) inside the pre_iter_hook causes the results of the find to be cached for use by the main result set when it iterates?
[01:08] <lifeless> yes
[01:08] <lifeless> they sit in the storm cache
[01:08] <lifeless> then by-id lookups will succeed
[01:08] <wallyworld_> cool. that wasn't obvious to me :-) storn noob ;-)
[01:09] <lifeless> reasonably common idiom in lp
[01:09] <wallyworld_> should there be a one line comment to that effect then in case anyone else reading the code is not sure - just to make it explicit?
[01:09] <wallyworld_> or if it's well known, no need
[01:10] <lifeless> its in a function called eager_load
[01:10] <lifeless> I think a comment would be adding neon lights
[01:11] <lifeless> it might be nice to have a function on StormResultSet that will completely iterate the set
[01:11] <lifeless> just for this
[01:11] <wallyworld_> suppose, but in general calling list() without assigning the result to anything may not always be "obvious" what it does. but that may just be me.
[01:17] <lifeless> I think it would be sad to have identical comments all over the code base saying this
[01:18] <thumper> \o/
[01:18] <thumper> stupid js tests now working
[01:18] <thumper> debugging the tests sucks badly
[01:18] <thumper> but they are working
[01:22]  * thumper wonders how to commit to lp:lazr-js
[01:22] <wallyworld_> thumper: did you find out how to get access to the DOM then?
[01:22] <lifeless> thumper: bzr lp-land
[01:22] <thumper> wallyworld_: no
[01:22] <thumper> wallyworld_: but I found the bug in my code
[01:22] <lifeless> thumper: after its reviewed :)
[01:22] <thumper> lifeless: it is reviewed
[01:22] <lifeless> thumper: it just uses the normal lp pqm
[01:23] <wallyworld_> thumper: that sucks. there has to be a better way to debug that sort of stuff
[01:23] <thumper> wallyworld_: agreed
[01:23] <thumper> wallyworld_: it was a real PITA
[01:23] <lifeless> thumper: can you mentor ian's review of https://code.launchpad.net/~lifeless/launchpad/bug-661988/+merge/48740 ?
[01:23] <wallyworld_> thumper: maybe my IDE can do it :-)
[01:23] <lifeless> wallyworld_: btw, why do you say 1000 items in an IN clause is an issue ?
[01:25] <wallyworld_> lifeless: that's when databases start to get inefficient. oracle actually has a hard 1000 item limit - it throws an exception. postgres i believe has a soft limit - it doesn't complain but performance goes south
[01:25] <lifeless> wallyworld_: I think its an overly naice heuristic
[01:26] <lifeless> wallyworld_: I've seen fine performance up at 15K items in IN clauses
[01:26]  * wallyworld_ wonders what naice means
[01:26] <lifeless> wallyworld_: *naïve*
[01:26] <wallyworld_> lifeless: wow. 15K items!!!!! that suggests to me that the query could be reconstructed
[01:26] <wallyworld_> /scould/should perhaps
[01:27] <lifeless> wallyworld_: that application had two different dbs; the output from the query on one db went into the query on the other.
[01:27] <lifeless> wallyworld_: but the point is, performance was fine
[01:28] <wallyworld_> sounds like a job for a temp table then
[01:28] <lifeless> wallyworld_: at 15 times the point of the 1000 limit you've seen before
[01:28] <wallyworld_> hmmm. i'll have to read mor eon what postgres can do. maybe i've been brainwshed by working with oracle
[01:28] <lifeless> wallyworld_: temp table would help if they were doing more than one query in the second db
[01:28] <lifeless> wallyworld_: this is one of those 'unless its been measured its irrelevant' cases
[01:32] <wallyworld_> sure. i've tended to use exists when the in list is large. but again, that may be my oracle bias coming out
[01:34] <lifeless> that seems bonkers
[01:34] <lifeless> the exists subsquery would have to have the IN list as well
[01:34] <mhall119> cjohnston: yup
[01:34] <lifeless> or you would have to write a temporary table, and select from that
[01:34] <lifeless> which is equivalent with any sensible implementation of IN
[01:37] <wallyworld_> i don't think oracle has a sensible implementation :-) it's always been a pita actually
[01:39] <wallyworld_> \o/ buildbot finished building db-devel rev 10180
[01:53] <StevenK> thumper: O hai?
[01:54] <StevenK> wallyworld_: ORA had some good ideas. They counter this with some *shocking* ones.
[01:54] <lifeless> StevenK: like what community means? :)
[01:54] <wallyworld_> lifeless: you took the words right out of my keyboard
[01:54] <wgrant> lifeless: The Launchpad definition of community sucks too :P
[01:55] <lifeless> wgrant: less
[01:55] <lifeless> wallyworld_: btw
[01:55] <lifeless> wallyworld_: for the bind variables patch
[01:55] <StevenK> lifeless: I was talking just in terms of the Oracle database product -- which has a vibrant community
[01:55] <wgrant> lifeless: The MP definition of community, that is.
[01:55] <lifeless> wallyworld_: test_bugtask_search has at least several patches that trigger the failure
[01:55] <lifeless> wgrant: even that fails less
[01:56] <StevenK> wgrant: In terms of what? Military Police? :-P
[01:56] <lifeless> s/patches/tests/
[01:56] <wallyworld_> lifeless: yeah, and also nascentupload tests too
[01:56]  * wallyworld_ is impatient for staging to get rev 10180 deployed
[01:57] <wgrant> Are we going to unfreeze as soon as we are QA'd past the merge?
[01:57] <lifeless> wallyworld_: while you wait, get that bind variables thing underway :)
[01:57] <lifeless> wgrant: yes
[01:57] <wgrant> Yay.
[01:57] <wallyworld_> wgrant: yeah
[01:57] <wallyworld_> lifeless: i have some recipe stuff to do first
[01:57]  * wallyworld_ has too many concurrent tasks
[01:58] <lifeless> bad idea ;)
[01:58] <wallyworld_> yes
[01:58] <StevenK> lifeless: So, in leiu of thumper -- I have fixed 683321 -- but I'm not happy with my fix
[01:58]  * wgrant throws fire at checkwatches.
[01:58] <lifeless> StevenK: shoot
[01:58] <lifeless> wgrant: so fix it
[01:59] <lifeless> wgrant: btw I did some analysis of the perf bugs you had in progress; hope it helped.
[01:59] <StevenK> lifeless: http://pastebin.ubuntu.com/563642/ is my diff
[01:59] <wgrant> Those statement counts of 10000 are a bit suspicious.
[01:59] <wallyworld_> wgrant: what was the end result of qa on rev 12321? did you come to the conclusion it is ok?
[01:59] <lifeless> wgrant: its not establising a new request context on each watch
[01:59] <lifeless> wgrant: very shallow fix
[02:00] <wgrant> wallyworld_: It seems to work, and hasn't broken anything that I can see. But I don't know Translations in depth.
[02:00] <lifeless> StevenK: whats unsatisfying about that ?
[02:00] <StevenK> lifeless: If you look at lib/lp/code/browser/sourcepackagerecipe.py, lines 528-545 and lines 631-650 (but my line count is off due to said diff)
[02:01] <wgrant> wallyworld_: I'm happy to qa-ok it, given how harmless the fix seems.
[02:01]  * wgrant qa-ok's it.
[02:01] <wallyworld_> wgrant: hennige is going to qa it as his SOD but that's a few hours away yet. we'll have to wait
[02:01] <StevenK> lifeless: Compare and contrast those two code blocks
[02:01] <wallyworld_> wgrant: ok. i'll make sure it's followed up. thanks
[02:01] <lifeless> StevenK: yes
[02:01] <StevenK> They're effectively indentical
[02:02] <lifeless> right
[02:02] <lifeless> needs to be pulled out sideways
[02:02] <StevenK> lifeless: Which is what is my question is -- how?
[02:02] <lifeless> looks like a method on RecipeRelatedBranchesMixin would come close to trivial
[02:04] <StevenK> lifeless: I was going to suggest RecipeTextValidatorMixin
[02:04] <lifeless> StevenK: even better
[02:05] <StevenK> lifeless: I might need a little more of a hint :_)
[02:06] <lifeless> StevenK: do you have the book 'refactoring' ?
[02:06] <StevenK> Nope
[02:06] <lifeless> I suggest you grab it; you should be able to expense it bu tcheck with your mgr first.
[02:07] <lifeless> the martin fowler one
[02:07] <lifeless> anyway
[02:07] <lifeless> what you need to do is:
[02:07] <lifeless> identify the common code
[02:07] <lifeless> if it surrounds some different code, you're going to need a callable or some such
[02:08] <lifeless> rearrange both locations until they are truely identical
[02:08] <lifeless> then move one of them to the mixin, turning local variables into parameters
[02:08] <lifeless> the other copy becomes just a call.
[02:18] <lifeless> StevenK: http://martinfowler.com/books.html#refactoring
[02:21]  * thumper is back now
[02:24] <StevenK> lifeless: Examples using Java and UML?
[02:24] <lifeless> yes
[02:24] <StevenK> And this is a *good* thing?
[02:24] <lifeless> the basic structures are the same
[02:24] <lifeless> there are some things that don't translate well to python
[02:25] <lifeless> e.g. accessors
[02:25] <lifeless> and balancing it with performance is a bit of an art
[02:25] <lifeless> but there is a tonne of good shit well presented
[03:11] <huwshimi> thumper: Just saw your post to the mailing list about lazr-js. When we were in Dallas he/we started to do the upgrade but hit failing tests with the new version of YUI. I'm not sure of the status of those problems though.
[03:11] <thumper> huwshimi: I recall that there was something going on
[03:11] <thumper> I didn't want to duplicate effort in fixing the tests
[03:14] <huwshimi> thumper: I don't remember the specifics of what was breaking, but I think it might have been something that Deryck couldn't fix directly
[03:14]  * thumper nods
[03:14] <thumper> I'll catch up with deryck in the morning
[03:20] <poolie> is this change to using courier as the fixed width font intentional?
[03:23] <wgrant> I've not heard anything about font changes recently.
[03:23] <poolie> in chromium, launchpad today started using a fairly ugly monospace font
[03:23] <wgrant> You didn't install msttcorefonts yesterday?
[03:23] <wgrant> Hmm.
[03:24] <wgrant> Chromium 9 was pushed out to Ubuntu yesterdayish.
[03:24] <poolie> it seems to want
[03:24] <poolie> font-family: "UbuntuBeta Mono","Ubuntu Mono",monospace;
[03:24] <huwshimi> poolie: It looks like if you don't have the Ubuntu Mono font it will default to whatever your browser/os default mono font is
[03:25] <poolie> I have "Ubuntu Beta Mono 17"
[03:25] <poolie> from "Walled Garden of Temptation"
[03:26] <poolie> is there a font "UbuntuBeta Mono"?
[03:26] <huwshimi> poolie: I don't think that would cut it
[03:26] <wgrant> poolie: That was the name we were given months ago, before a mono variant existed.
[03:26] <wgrant> Apparently they did not follow their scheme.
[03:26] <poolie> apparently not
[03:27] <poolie> do either of you have "Ubuntu Mono" or "UbuntuBeta Mono"?
[03:27] <huwshimi> poolie: nope
[03:27] <huwshimi> I should though
[03:27] <huwshimi> poolie: I can tell you how to rename the font
[03:28] <poolie> i guess that chromium's change may have it no longer interpreting "monospace" as meaning the system monospace font
[03:28] <poolie> which is probably a bug there too, but lp has a bug if it's asking for ubuntu fonts that don't/won't exist
[03:32] <poolie> huwshimi, how?
[03:32] <poolie> istr you can make aliases in fontconfig
[03:32] <huwshimi> poolie: The way I would do it would be to modify the font itself (or a copy of the font)
[03:33] <huwshimi> poolie: but you might be right about using aliases
[03:35] <lifeless> well
[03:35] <lifeless> we shouldn't have poolie rename the font
[03:35] <lifeless> we should update lp to use the name actually used by the font
[03:36] <james_w> well, I doubt the number will be in the final name
[03:36] <huwshimi> lifeless: I suspect that poolie has a pre-release version with a version number in the name
[03:36] <poolie> right
[03:37] <poolie> i think _everyone_ has a version number in the font
[03:37] <poolie> if they have it at all
[03:38] <huwshimi> poolie: I guess people will have different version numbers though
[03:38] <poolie> https://bugs.launchpad.net/launchpad/+bug/714381
[03:38] <_mup_> Bug #714381: launchpad css asks for "UbuntuBeta Mono" font that doesn't exist <css> <easy> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/714381 >
[03:38] <poolie> huwshimi, yeah
[03:38] <poolie> i find that a bit weird, but i guess that's their decision
[03:39] <poolie> we could ask for 17
[03:39] <poolie> or prefer 20, 19, 18, 17, ...
[04:00] <huwshimi> poolie: neither Chrome or Firefox respect the os's default font it seems.
[04:19]  * thumper EODs
[04:31]  * wallyworld_ wonders why staging seems to be taking so long to come up again
[04:32] <lifeless> wallyworld_: we'll find out when spm returns
[04:32] <wallyworld_> lifeless: is he the one who also needs to then do the merge into devel etc
[04:57] <wallyworld_> lifeless: i'm off to pickup the kid from school. will check back in 30 minutes or so to see the status of staging
[04:58] <lifeless> wallyworld_: see -ops
[04:58] <lifeless> wallyworld_: will need stubs input to recover
[05:32] <lifeless> wgrant: view-source:https://qastaging.launchpad.net/ubuntu/+archive/asuka-wants-to-get-rocked/+index
[05:32] <lifeless> At least 80 queries/external actions issued in 9.28 seconds
[05:32] <lifeless> wgrant: I'm just impressed its rendering on qastaging
[05:35] <wgrant> lifeless: Oh wow.
[05:35] <wgrant> That's nice.
[05:36] <wgrant>     At least 4 queries/external actions issued in 0.08 seconds
[05:36] <lifeless> ?!
[05:36] <wgrant> Ah, I can't see it.
[05:36] <wgrant> That's fewer queries than I would have expected for an Unauthorized, though.
[05:36] <lifeless> oh, needs to be enabled ?
[05:36] <wgrant> I guess it reinitialises the view.
[05:36] <wgrant> Yeah.
[05:36] <lifeless> yeah, it does
[05:37] <lifeless> https://qastaging.launchpad.net/ubuntu/+archive/asuka-wants-to-get-rocked should work for you now
[05:38] <lifeless> I wish we had a discrete menu at the top like gmail does
[05:40] <wgrant> Hm?
[05:45] <huwshimi> lifeless: You mean like a global navigation/user specific options sort of thing?
[05:46] <lifeless> yes
[05:46] <lifeless> huwshimi: oh excellent, you are here
[05:46] <lifeless> is span still appropriate to wrap something inline in a paragraph ?
[05:46] <lifeless> silly tal wants hierarchical containers :(
[05:47] <huwshimi> lifeless: Yes, a span is good.
[05:50] <wgrant> lifeless: If you don't actually want the element to be there, you can just use a <tal:ANYTHING replace="foo" />
[05:51] <huwshimi> lifeless: I was thinking the exact same thing about the global nav earlier today. I came to the conclusion that it depends what launchpad wants to be. At the moment, once you get to a project you're pretty much stuck there (except by using the links in the footer or clicking your name at the top right). This makes Launchpad good if you want Launchpad to be quite invisible. If Launchpad wants to be more collaborative
[05:51] <huwshimi>  and feel like a destination itself (rather than the project being the destination) then I think some global navigation would go a long way to making Launchpad more whole.
[05:52] <huwshimi> I think.
[05:52] <wgrant> AFAICT the point of LP 3.0 was to make LP disappear.
[05:52] <wgrant> The project was made the prominent entity.
[05:52] <huwshimi> wgrant: Right. So it depends what Launchpad wants to be.
[05:53] <wgrant> Exactly.
[05:54] <huwshimi> I get the feeling that Launchpad may move back away from that
[05:56] <lifeless> FWIW I'd be looking at a balancing act
[05:56] <lifeless> I think lp is terribly hard to navigate at the moment
[05:56] <lifeless> but its easy to jump around within a project on lp.
[05:58] <huwshimi> lifeless: I guess it's something we should talk to jml about?
[05:59] <lifeless> wgrant: ah yesm cool. thanks.
[06:00] <lifeless> huwshimi: I think that would be a good start; OTOH this is arguably small fry right now given the massive lack web2.anything ;)
[06:00] <huwshimi> lifeless: It might be small fry, but I think it's these little steps that quickly add up to creating a lot of impact.
[06:01] <huwshimi> lifeless: I'll shoot jml an email about it
[06:01] <lifeless> huwshimi: cool
[06:02] <huwshimi> lifeless: Do you have a minute to talk about another navigation issue?
[06:03] <lifeless> sure
[06:04] <lifeless> huwshimi: trade you for a little dom glue
[06:04] <huwshimi> lifeless: Deal.
[06:04] <lifeless> so, what can I help you with ;)
[06:05] <poolie> draft post about web_link: http://blog.launchpad.net/?p=1916&preview=true
[06:06] <huwshimi> lifeless: I was wondering if you knew what technical advantages we gain by having our "apps" (bugs, code etc.) on different sub-domains, if any.
[06:06] <poolie> :)
[06:06] <lifeless> huwshimi: it costs us
[06:07] <huwshimi> lifeless: Oh, in what way?
[06:07] <lifeless> huwshimi: its complex to do, to maintain, has a performance cost on domain switches.
[06:07] <huwshimi> lifeless: Right.
[06:07] <lifeless> clicking on code, for instance, -> 6 second delay to do SSL handshake (for you or I
[06:07] <poolie> huwshimi, i think it's a bit of an artifact of there once being a plan to make them more separated
[06:08] <lifeless> its a solution to one ui problem, which is 'what url to give a different rendering of a single object'
[06:08] <huwshimi> poolie: yeah, I read Mark's blog post about it.
[06:08] <lifeless> huwshimi: url for that?
[06:08] <huwshimi> lifeless: http://www.markshuttleworth.com/archives/30
[06:09] <poolie> :)
[06:09] <poolie> keeping people in the zone is good, but i don't know that splitting the url is the most useful thing to get there
[06:09] <poolie> but that's 5 years ago now
[06:10] <huwshimi> lifeless: I'm just speculating now, and really just doing research, but would would be the cost of migrating off subdomains?
[06:10] <lifeless> huwshimi: I dislike estimating for other people.... but I think a feature squad could do the heavy lifting in a week.
[06:11] <lifeless> huwshimi: there are several steps needed:
[06:11] <lifeless>  - we need to map the existing content into the main url hierarchy. E.g. we could put +blueprint at the end of a url to mean what currently blueprints....../thing/ means
[06:12] <lifeless>  - we need to decide on a forwarding strategy for the old urls (e.g. do it in apache, or in the appserver indefinitely or ...)
[06:12] <lifeless>  - we need to assess the usability impact - and benefits [this is a LEP level thing I think]
[06:12] <lifeless>  - and we need to execute
[06:13] <lifeless> I *think* some clever code in the publisher could do the initial translation for us, but we'd want a way to be really clean internally going forward.
[06:14] <wgrant> Moving the pages off subdomains is very easy.
[06:14] <wgrant> There may be some slight issues getting the facet breadcrumbs to work properly.
[06:14] <wgrant> But that's about it.
[06:15] <lifeless> wgrant: right; and we have to retain urls to show all the facets
[06:15] <wgrant> We already have those.
[06:15] <wgrant> But we might want to rename them.
[06:15] <wgrant> (+code-index, +bugs-index, ettc.)
[06:16] <lifeless> ah, I hadn't actually read that bit of glue; ok, so yes, what I thought could be written has been.
[06:16] <wgrant> There are some views (mostly Code and Translations) that exist only on the relevant domain.
[06:16] <stub> Our bzr-git is still oldformat bzr repo
[06:17] <wgrant> But they are very much the exception.
[06:17] <lifeless> also a source of user complaints
[06:17] <wgrant> Yes.
[06:18] <lifeless> notwithstanding the issue with sending api calls to the right place, I'd like to fix that.
[06:18] <wgrant> Particularly the lack of Branch:+index.
[06:18] <wgrant> It vanished a couple of months back :(
[06:18] <lifeless> success
[06:18] <lifeless> 15 queries/external actions issued in 0.18 seconds • lifeless •
[06:18] <lifeless> huwshimi: ok, so
[06:18] <lifeless> huwshimi: I've got this little bit of text I want to show up beside my login
[06:19] <lifeless> huwshimi: the problem is that it has to be rendered *after* all the rest of the page.
[06:19] <huwshimi> lifeless: Yeah thanks for that. It was very helpful.
[06:19] <lifeless> huwshimi: its only going to show for developers
[06:19] <lifeless> whats the best way to make it show up where the login name is, but have it evaluated at the end of the page.
[06:19] <lifeless> e.g. is a <script> segment appropriate, or something else ?
[06:20] <huwshimi> lifeless: What does it need that is only available at that point?
[06:20] <lifeless> the amount of time that the page takes to render
[06:20] <huwshimi> lifeless: Ah right :)
[06:21] <lifeless> it /probably/ needs to be fixed up client side.
[06:22] <huwshimi> lifeless: render time, including javascript execution?
[06:22] <lifeless> server render time
[06:22] <huwshimi> lifeless: Ah ok
[06:22] <lifeless> adding in javascript render time would be an awesome bit of filigree but its not my first target.
[06:22] <stub> lifeless: You could set a cookie after the page has been generated (and before returned to the client) containing the details, and have the javascript display the contends
[06:23] <lifeless> stub: thats possible; could also just render the javascript to set it with the contents.
[06:23] <wgrant> stub: Race race race.
[06:24] <stub> wgrant: Shouldn't be a race - cookies are sent in the header, and they are called headers for a reason. I suspect I'm overly optimistic here :)
[06:24] <lifeless> huwshimi: my js is extremely rusty - the last time I did significant stuff with it was in 97
[06:24] <wgrant> stub: It'll race with other pages, though.
[06:24] <lifeless> huwshimi: so I'm wondering if you'd care to proffer a little snippet
[06:24] <huwshimi> lifeless: Where does it get the timestamp from, or do you want to generate it with the javascript?
[06:25] <stub> So we need to inject the tag after generating the page and before returning it to the client. No JS needed, no race conditions
[06:25] <lifeless> huwshimi: I propose to put the js in base-layout.pt
[06:25] <lifeless> huwshimi: where the current comment listing the page metadata is
[06:26] <lifeless> huwshimi: and I can render the javascript with the right duration immediately
[06:26] <stub> Minor publisher hack to our collection of minor publisher hacks we call our publisher.
[06:26] <lifeless> stub: I'm alittle worried about where in the publisher I'd need to poke to make that happen; doing a 5-line js render seems cheaper
[06:26] <lifeless> stub: +
[06:27] <lifeless> stub: doing it as js lets us get js render times eventually as well
[06:27] <stub> The publisher basically does 'return foo(request)'. Change that to 'body = foo(request); body.replace('$$$ I CAN HAZ RENDERTIME $$$', str(rendertime)); return body
[06:28] <lifeless> stub: right, thats expensive on our big pages
[06:28] <lifeless> measurably so
[06:28] <huwshimi> lifeless: If you're generating the timestamp with the javascript you'll have issues with javascript execution times
[06:28] <lifeless> huwshimi: not a timestamp; string description of duration.
[06:29] <huwshimi> lifeless: Ah ok, so it's already been generated? Sorry I'm a bit confused :)
[06:29] <lifeless> huwshimi: visit any old launchpad page
[06:29] <lifeless> view the source and scroll to the bottom
[06:29] <stub> I'm causing confusion because I'm talking page generation time and this conversation is about client side rendering time I realize
[06:30] <lifeless> stub: no, its a bit about both.
[06:30] <lifeless> stub: so on particular confusion, but I think its worth having one change that will do both eventually.
[06:30] <lifeless> huwshimi: so at the bottom there is a comment block
[06:30] <lifeless> with things like '15 queries/external actions issued in 0.18 seconds' in it
[06:30] <huwshimi> lifeless: yeah got it
[06:31] <lifeless> huwshimi: I want to show that string (perhaps more compactly) to the left of my name in the login area
[06:31] <huwshimi> lifeless: Right, I'm with you
[06:32] <poolie> i wish lp would stop sending:
[06:32] <poolie> ** Changed in: bzr
[06:32] <poolie>     Assignee: Registry Administrators (registry) => Curtis Hovey (sinzui)
[06:32] <poolie> ** Changed in: bzr
[06:32] <poolie>     Assignee: Curtis Hovey (sinzui) => (unassigned)
[06:32] <wgrant> You want it to collapse them?
[06:32] <poolie> huwshimi, +1, i think that would be great
[06:33] <huwshimi> lifeless: Because it is outside the entire <html> definition you'll probably have to do something a little hacky to get it to work. Unless I'm overlooking something, but I don't think I am. Let me do a quick test and I'll give you some code
[06:33] <huwshimi> poolie: About subdomains?
[06:33] <lifeless> huwshimi: we can put it in the html easily
[06:34] <lifeless> huwshimi: thats a 5 second change
[06:35] <huwshimi> lifeless: I guess the real issue is that it is not inside a single element to nicely pull it out.
[06:35] <lifeless> huwshimi: how do you mean ?
[06:35] <poolie> about subdomains but also about showing the db query count
[06:35] <lifeless> huwshimi: I can put it into the javascript we output
[06:35] <lifeless> poolie: db count is me :)
[06:35] <lifeless> poolie: I'm nabbing huwshimi for help.
[06:36] <huwshimi> lifeless: Oh I see you'd modify the javascript server side to set a javascript var?
[06:36] <lifeless> yes
[06:36] <huwshimi> lifeless: Oh, easy then :)
[06:36] <lifeless> I can write out the js all prepped and ready to go
[06:36] <lifeless> exactly
[06:37] <huwshimi> lifeless: ok let me give you some code
[06:37] <huwshimi> you can stick it where you like, it doesn't matter when it is executed then.
[06:37] <huwshimi> one sec
[06:42] <lifeless> huwshimi: obviously I can add a span or what have you at the top to get replaces
[06:42] <lifeless> *replaced*
[06:42] <lifeless> huwshimi: and I can take care of all the logic for when to show/not show.
[06:42] <huwshimi> lifeless: Sure
[06:43] <huwshimi> http://paste.ubuntu.com/563723/
[06:43] <huwshimi> lifeless: ^ that should be roughly it
[06:43] <huwshimi> lifeless: if you want you could add a dive with javascript as well so you don't have to add any html to render
[06:45] <huwshimi> lifeless: Ouch, actually there is one bug
[06:45] <lifeless> does that replace the entire location bar
[06:45] <huwshimi> lifeless: yes :)
[06:45] <lifeless> ok, well I'll wrap this in when-to-show and the render time
[06:52] <lifeless> right, thats all glued in
[06:52] <lifeless> just needs the tweak to not replace it all
[06:54] <huwshimi> lifeless: ok, for that you need it to look like this: http://paste.ubuntu.com/563729/
[06:55] <lifeless> huh
[06:55] <lifeless> wouldn't this work ?
[06:55] <huwshimi> lifeless: That will create the extra div and everyone
[06:55] <huwshimi> *everything
[06:55] <lifeless> http://pastebin.com/pSek6jTi
[06:56] <lifeless> ah, it renders quirkily my way
[06:56] <huwshimi> lifeless: Yes, but then you don't have a parent element to control it's position with'
[06:57] <huwshimi> lifeless: Yeah it'd probably look a bit strange without a float or anything
[06:57] <lifeless> so
[06:57] <lifeless> I can create the dic up front
[06:57] <lifeless> give it a static 'loading...' message
[06:57] <huwshimi> lifeless: Yes that would work
[07:03] <lifeless> sweet
[07:03] <lifeless> it sits a little close to the person icon
[07:03] <poolie> lifeless, bug 703807 looks a lot like a squid problem
[07:03] <_mup_> Bug #703807: "easy_install pyOpenSSL" says "error: Unexpected HTML page found at http://launchpad.net/pyopenssl/main/0.11/+download/pyOpenSSL-0.11.tar.gz" <Launchpad itself:Triaged> <pyOpenSSL:New> < https://launchpad.net/bugs/703807 >
[07:04] <poolie> since it shows up consistently on one proxy
[07:04] <poolie> just thought you might be amused
[07:04] <lifeless> s/amused/horrified/
[07:04] <poolie> :)
[07:05] <wgrant> poolie: It depends on the file.
[07:05] <wgrant> poolie: Some work fine on both.
[07:05] <poolie> i have a tcpdump here but i don't know if it really shows anything interesting other than what's in the header
[07:05] <wgrant> Others work only on one sometimes.
[07:05] <poolie> wgrant, true
[07:05] <lifeless> poolie: I doubt that its squid; squid will be doing what its told.
[07:05] <wgrant> It may be that only one has cached bad responses.
[07:05] <wgrant> The other managed to get a good one.
[07:05] <poolie> i don't think it's a squid bug but it may be a squid issue
[07:05] <poolie> whether that is bad configuration, bad data on disk, bad cache guidance from lp
[07:05] <lifeless> uhm
[07:06] <lifeless> So I still doubt that; I bet if squid wasn't there we would get users complaining from time to time
[07:06] <lifeless> squid probably makes the issue, whatever it is, more visible when it happens.
[07:06] <poolie> wgrant, now that would be interesting if we can find a url that works on banana and not nutmeg
[07:06] <poolie> well, it probably makes it sticky
[07:07] <poolie> lifeless, how likely is it that it could cache a content-type and a body that weren't originally sent together?
[07:07] <poolie> i would have thought pretty unlikely
[07:07] <wgrant> 14:31 < wgrant> At the moment, http://launchpadlibrarian.net/58498441/pyOpenSSL-0.11.tar.gz gets the right type from nutmeg, but the wrong from banana.
[07:07] <lifeless> poolie: cosmic ray unlikley.
[07:07] <wgrant> That was a couple of weeks ago.
[07:08] <poolie> wgrant, that's also what i'm getting today
[07:08] <wgrant> Ah.
[07:08] <wgrant> True.
[07:08] <lifeless> huwshimi: if you wanted to eyeball this and see how it looks - lp:~lifeless/launchpad/showtimes has the patch.
[07:08] <huwshimi> lifeless: Do you want a bit more styling for it? Is this a permanent thing? At the moment the css applied is kind of bad, but I can give you some proper stuff?
[07:08] <poolie> if we found that they swapped around either for this url, or for different urls, that would be quite interesting
[07:08] <huwshimi> lifeless: OK, I'll take a look
[07:09] <wgrant> Right, I thought I found such an example, but I was confused.
[07:09] <lifeless> huwshimi: to play with it, pull/merge that branch in, run it, visit 'https://launchpad.dev/+feature-rules' and add a rule 'visible_render_times default 1 on'
[07:09] <poolie> do you know off hand if these machines will respect any cache-busting headers?
[07:09] <huwshimi> lifeless: Actually how do I run your branch locally?
[07:09] <huwshimi> lifeless: Do I stick it in lp-branches?
[07:10] <wgrant> poolie: Uh, did you actually look at launchpad.net/debian?
[07:10] <lifeless> huwshimi: make a branch of your own to hold it, then run 'bzr pull --overwrite lp:~lifeless/launchpad/showtimes'
[07:10] <wgrant> poolie: I made sid the dev focus this morning, when I created wheezy.
[07:10] <wgrant> lp:debian/foo now resolves to sid.
[07:10] <huwshimi> huwshimi: Can I just create that initial one with rocketfuel-branch?
[07:10] <poolie> hooray
[07:10] <poolie> no, i didn't look closely enough
[07:10] <wgrant> Heh
[07:11] <huwshimi> ugh
[07:11] <huwshimi> lifeless: Can I just create that initial one with rocketfuel-branch?
[07:11] <huwshimi> I was talking to myself again
[07:11] <lifeless> huwshimi: yes, you can
[07:12] <poolie> wgrant, so nothing more needs to be done? or should we rejigger stacking?
[07:12] <huwshimi> lifeless: Thanks, I'm still a noob :)
[07:12] <poolie> i suppose that would mean unstacking the sid branches
[07:12] <wgrant> poolie: We could restack everything if we really wanted to. But the benefit is negligible.
[07:12] <poolie> hm
[07:12] <poolie> ok
[07:12] <wgrant> We need a way to do that sort of thing, but I don't think we have it at the moment.
[07:12] <wgrant> Actually.
[07:12] <wgrant> Hmm.
[07:12] <wgrant> I guess we probably should do that.
[07:13] <poolie> what did you do to change the focus?
[07:13] <wgrant> Or we are going to have multi-level stacking. And I guess that's not going to work very well.
[07:13] <lifeless> sometimes I think drmo doesn't read blog posts. sigh.
[07:13] <wgrant> ~registry can change the status on +edit of Debian's distroserieses.
[07:13] <wgrant> There's no link, but URL hacking works.
[07:13] <lifeless> we want /sid/ to be unstacked
[07:13] <poolie> actually https://launchpad.net/debian doesn't say which one is the development focus
[07:13] <wgrant> The dev focus is the "Current Development" series.
[07:13] <lifeless> and the rest stacked on sid
[07:14] <poolie> neither does https://launchpad.net/debian/sid
[07:14] <wgrant> No, because it's not explicit for distributions.
[07:14] <wgrant> It's implied from the status.
[07:14] <poolie> i feel less bad about not seeing it now :)
[07:14] <poolie> ah, "active development" implies that?
[07:14] <wgrant> Er, yeah, Active Development, not Current Development
[07:14] <poolie> well that's obvious
[07:15] <wgrant> That's 2005.
[07:15] <poolie> ?
[07:15] <poolie> the ui design here is from 2005?
[07:15] <wgrant> The data model is.
[07:15] <wgrant> Products have a dev focus.
[07:15] <wgrant> Distributions do not.
[07:16] <wgrant> And yes, most of the UI design is too :)
[07:16] <lifeless> review plox https://code.launchpad.net/~lifeless/launchpad/showtimes/+merge/48754
[07:17] <lifeless> huwshimi: its visible_render_time - no s. my bad.
[07:18] <huwshimi> lifeless: Ah thanks
[07:18] <poolie> nice
[07:19] <lifeless> thanks
[07:20] <lifeless> huwshimi: commit -2 is the meat of the change
[07:20] <lifeless> huwshimi: you can see that with 'bzr diff -c -2'
[07:21] <wgrant> We don't have any tools at the moment to mass-restack branches, do we?
[07:21] <poolie> nup
[07:21] <lifeless> other than branch-distro
[07:21] <lifeless> no
[07:21] <poolie> well, shell scripts
[07:21] <wgrant> branch-distro cheats.
[07:21] <poolie> i wonder what degree of tool-building would be worthwhile?
[07:21] <huwshimi> huwshimi: ok cool thanks. Did you want me to give you some css to make that spaced a bit better?
[07:21] <wgrant> Right. It's really easy to script it up. Just wondering if we had an existing solution.
[07:21] <wgrant> I think most sid branches should already contain ~all the data anyway.
[07:21] <wgrant> But it would be nice to formalise that.
[07:22] <lifeless> huwshimi: now you are talking to yourself :)
[07:22] <huwshimi> ugh, I keep doing that!
[07:22] <wgrant> Perhaps we want to revert the dev focus until we do that.
[07:22] <lifeless> huwshimi: sure, that would be cool
[07:22] <huwshimi> lifeless: ok no problems :)
[07:22] <lifeless> huwshimi: it doesn't matter a great deal, but we might find that interested users want to see this or something.
[07:22] <huwshimi> lifeless: Sure
[07:23] <lifeless> huwshimi: so I don't think it should be /ugly/
[07:24] <poolie> lifeless, can i see a screenshot?
[07:28] <wgrant> poolie, lifeless: We should probably work this out before we run branch-distro, which will create 20000 new branches stacked on wheezy rather than sid. It sounds like we want to reconfigure --unstacked all of sid's branches (should be cheap, since revs should have appeared in sid first anyway), then hack branch-distro to stack on there instead of the new series.
[07:28] <poolie> bug 714414
[07:28] <_mup_> Bug #714414: unstack debian sid branches <code-hosting> <stacking> <Launchpad itself:Triaged by canonical-bazaar> < https://launchpad.net/bugs/714414 >
[07:28] <huwshimi> lifeless: Do you want a patch or something?
[07:29] <lifeless> huwshimi: patch sure, or you could commit and push and I'll pull in your branch
[07:29] <huwshimi> lifeless: ok I'll commit
[07:30] <poolie> wgrant, right, so i wonder if that should just be $something|xargs -n1 bzr reconfigure --unstacked, and ask a losa to run that
[07:30] <lifeless> poolie: just trying to remember the hostname to use to sftp up the screenshot
[07:30] <wgrant> poolie: Pretty much, I think.
[07:30] <wgrant> Or possibly a harness.
[07:31] <poolie> what does 'harness' mean in this context?
[07:31] <wgrant> As in 'make harness', sorry.
[07:32] <wgrant> Giving us access to the usual codehosting Python APIs.
[07:32] <wgrant> Allowing us to list and open branches and stuff...
[07:32] <wgrant> A smartserver restack is server-side, right?
[07:32] <poolie> hm
[07:33] <poolie> this is the thing that opens up a python shell with an lp object?
[07:33] <wgrant> assuming it is, we just need a member of ~ubuntu-branches, and launchpadlib...
[07:33] <poolie> i think that's true
[07:33] <poolie> it does depend on keeping the connection open, but that could be run from the dc
[07:33] <wgrant> Right.
[07:33] <huwshimi> lifeless: lp:~huwshimi/launchpad/showtimes
[07:34] <huwshimi> lifeless: Tell me if that looks ok
[07:34] <poolie> lifeless, i think jorge recommended 'shutter' which can upload them various places
[07:36] <lifeless> huwshimi: I think you haven't pushed
[07:37] <huwshimi> lifeless: Oh, it says it's done...
[07:38] <huwshimi> lifeless: oh, I've failed.
[07:38] <huwshimi> lifeless: I'm trying to do too many things
[07:38] <huwshimi> lifeless: one sec
[07:38] <huwshimi> lifeless: I pushed it without the changes :D
[07:40] <huwshimi> lifeless: OK, try now.
[07:42] <lifeless> thanks, trying
[07:42] <lifeless> poolie: http://people.ubuntu.com/~lifeless/showtime.png
[07:42] <lifeless> thats without huw's fixes.
[07:43] <lifeless> huwshimi: thanks, pushing that into the proposal
[07:43] <huwshimi> lifeless: Great.
[07:45] <huwshimi> lifeless: Just before I head off, in terms of the subdomain stuff, what are your initial reactions to the idea of change to a different url structure? I don't want to push the issue if I should really just be leaving it alone.
[07:48] <lifeless> uhm
[07:48] <lifeless> so there are three things you might mean
[07:49] <lifeless> if you mean 'lets use one domain for the app, one for apis and the librarian/apt-archives/etc off to the side' - fine by me
[07:49] <lifeless> on a technical level that has many advantages
[07:49] <lifeless> if you mean use a different way of generating urls.
[07:49] <lifeless> e.g. /objectid
[07:49] <lifeless> and being much less 'object traversal and guessable'
[07:50] <lifeless> well, perf wise that will have implications (neither good or bad per se - just change we need to accomodate)
[07:50] <lifeless> and I think it needs to be vetted in terms of usability
[07:50] <lifeless> one of the early design considerations was that our urls should be tellable
[07:50] <lifeless> (vs copiable)
[07:51] <lifeless> if you mean something in between the two, my reaction is in between the two :)
[07:52] <huwshimi> lifeless: ok, I'm really only thinking about removing the bugs.LP code.LP etc. and somehow merging them into the main urls
[07:52] <huwshimi> which would be your first option
[07:52] <lifeless> I know jml is interested in doing that
[07:52] <lifeless> and as I say, technically this would be great in many ways.
[07:53] <huwshimi> lifeless: I had a brief discussion with him about and his concern was the technical impact of it, which by the sounds of things would affect things positively.
[07:53] <lifeless> I think it would a bit of a wash UI wise in some ways - some things like 'type in bugs.' would become 'suffix with +bugs', or whatever.
[07:53] <lifeless> huwshimi: I'm reasonably sure he knows my opinion here; happy to write it down for reference if you like
[07:54] <lifeless> I *don't* think this is a high priority in terms of improving the UI or experience of LP; but thats not grounded in science.
[07:55] <huwshimi> lifeless: OK thanks very much. I'll do some more thinking about it then.
[07:57] <lifeless> the things I think are key priorities are:
[07:57] <lifeless>  - making it feel snappy
[07:57] <lifeless>  - making doing the most common things easy to do
[07:57] <lifeless> for the former more extensive API use vs page loads will help considerably.
[07:57] <lifeless> E.g. search pagination should not be a page load.
[07:58] <lifeless> for the latter, I think doing some extensive log analysis could be a goldmine for finding out what folk do the most. And then we can start including that data in our scheduling discussions.
[08:00] <huwshimi> lifeless: How much impact does the ssl stuff have?
[08:01] <huwshimi> is that delay every time you switch subdomain?
[08:01] <lifeless> our SSL cache is set (IIRC) to 6 hours expiry now
[08:01] <lifeless> so users should only perceive it when either:
[08:02] <lifeless>  a - their brower switches backend IP (should be never, but you can't be sure without reading the browser source code :P)
[08:02] <lifeless>  b - they've just started using the site in a new browser session or after a many hour delay
[08:03] <huwshimi> I guess b would be once or twice daily then
[08:04] <lifeless> well, 6 hour gap
[08:04] <lifeless> (I think thats what its at)
[08:04] <lifeless> I'm negotiating with ubuntu-server team to apply the memcached ssl cache patch to apache for us
[08:05] <lifeless> if we get that in a backport for lucid, we can push it up to 24 hours and have it shared between apaches
[08:05] <lifeless> that should mean ~ never for our more active users.
[08:05] <huwshimi> lifeless: Ok, so in terms of performance subdomain stuff is negligible
[08:06] <lifeless> we can reduce the impact till its largely ignorable. there will always be a 6 second warmup for folk near gmt+12, but the distributed ssl front ends we're looking at will mitigate that a great deal
[08:07] <huwshimi> lifeless: OK thank.
[08:07] <lifeless> huwshimi: shiny theming on the render times
[08:07] <huwshimi> lifeless: Ok cool, that's ok then?
[08:08] <lifeless> yeah, I just took it before, ran it up now.
[08:08] <lifeless> iz nice.
[08:08] <lifeless> its a little bit of a shame that the bullet point is now a different size
[08:08] <lifeless> but 'meh'
[08:09] <huwshimi> lifeless: We can fix that if we care enough
[08:10] <lifeless> huwshimi: wait till it annoys you
[08:10] <huwshimi> lifeless: Haha
[08:10] <lifeless> huwshimi: this will go live monday next week
[08:10] <lifeless> huwshimi: as I'm not going to push it via r-c, and friday will be too late for it.
[08:11] <huwshimi> lifeless: For some reason those bullet points annoy me any way, so watch out otherwise I'll delete them all :P
[08:11] <lifeless> huwshimi: wouldn't bother me; I was following suit
[08:11] <lifeless> huwshimi: now, to show javascript render times
[08:12] <lifeless> huwshimi: I imagine we'd put a little <script> at the top of the html to grab a timestamp as the page starts loading. Probably not even aa YUI call; bare js.
[08:13] <lifeless> huwshimi: then this code block at the end could grab that and subtract to figure out the interval; but would it be realistic - that is, would the overlays for bug task buttons etc have all rendered by then ?
[08:13] <huwshimi> lifeless: Yeah that will be the hard bit.
[08:13] <huwshimi> lifeless: Are you doing this so that the time is in our face the whole time?
[08:13] <lifeless> is there a 'bing, its cooked, ready to eat' event ?
[08:13] <lifeless> huwshimi: hell yes.
[08:13] <huwshimi> lifeless: Awesome
[08:14] <lifeless> i'm a huge fan of continual partial awareness of things that need optimising
[08:14] <lifeless> if you can't see it, and its not your primary concern, it won't get looked at.
[08:15] <huwshimi> lifeless: There's a few dom states for things like that. I think you might be able to use the 'ready' state. I think DOM and javascript execution is done then, but I'm not sure if all execution is done and I don't think images are either
[08:15] <huwshimi> lifeless: I think it's a good idea.
[08:16] <lifeless> huwshimi: an approximation may still be usfeul
[08:17] <huwshimi> lifeless: Yeah, you should be able to get some idea from comparing the numbers to a browser profiler (like the chrome one or firebug or something).
[08:17] <lifeless> huwshimi: right now I'm not likely to add the js times myself
[08:18] <lifeless> huwshimi: but I'd be delighted to help you overcome any issues you might have adding that, if you are interested in doing so
[08:18] <huwshimi> lifeless: Haha.
[08:18] <lifeless> primarily because I want to get the server side /sorted out/
[08:18] <huwshimi> lifeless: Did you say that someone is looking into lazy loading the javascript?
[08:18] <lifeless> huwshimi: deryck has mumbled various things
[08:19] <lifeless> there is a usable combo loader in lazr-js; I helped sidnei optimise that a few weeks ago
[08:19] <lifeless> huwshimi: oh, the other perf advantage of one domain
[08:19] <lifeless> less repeated downloads of javascript
[08:20] <huwshimi> lifeless: Yeah, I was surprised to see we don't stick all the js/css/images on it's own server
[08:22] <lifeless> huwshimi: for first access, another ssl handshake == slower
[08:22] <huwshimi> lifeless: Ah right
[08:22] <huwshimi> lifeless: disconnecting for one minute
[08:26] <huwshimi> lifeless: Is the media served through it's own apache instance though?
[08:27] <lifeless> so we have 2 sets of media
[08:27] <lifeless> we have user media
[08:27] <lifeless> and system media
[08:27] <lifeless> system media is treated like css etc; its static files on the same domain as the page, so no new ssl handshakes.
[08:27] <lifeless> user media is put on the librarian
[08:28] <lifeless> the librarian is launchpadlibrarian.net (for public files) and *.restricted.launchpadlibrarian.net for private files
[08:29] <lifeless> so user branding will generate (at least one) ssl handshake.
[08:30] <huwshimi> ssl is such a pain
[08:40] <StevenK> huwshimi: I'd rather it was using SSL :-)
[08:40] <lifeless> technically speaking, we're staying on pure ssl
[08:40] <lifeless> :)
[08:57] <adeuring> good morning
[09:02] <mrevell> Hello
[09:02] <Ursinha> good morning launchpadders
[09:10] <wgrant> lifeless: Still around?
[09:10] <lifeless> somewhat
[09:11] <wgrant> lifeless: What do you think of http://pastebin.ubuntu.com/563762/? It may need loop-tunerising, but it's probably OK.
[09:13] <lifeless> wgrant: well it will work, but isn't it going to double our disk usage?
[09:13] <wgrant> lifeless: I suspect our disk usage is already doubled.
[09:14] <wgrant> lifeless: Since all the new data will be going into sid first.
[09:14] <lifeless> wgrant: well the importer is halted for now
[09:14] <lifeless> wgrant: isn't it ?
[09:14] <wgrant> lifeless: I mean historically.
[09:14] <wgrant> New revs are imported into the stacked sid branches.
[09:14] <lifeless> ah yes
[09:14] <lifeless> so anyhow
[09:14] <wgrant> Only after ten days do they enter the stacked-on branch.
[09:15] <lifeless> I think this will work
[09:15] <wgrant> We probably want to later on manually "
[09:15] <lifeless> loop tuning would be pointless
[09:15] <wgrant> restack" the rest of the series by recloning.
[09:15] <wgrant> But that can happen later.
[09:15] <wgrant> Right.
[09:15] <lifeless> we should get a report of disk waste and some code to discard duplicate revs and tune
[09:15] <lifeless> wgrant: gc, no need to reclone.
[09:15] <lifeless> wgrant: specialised pack()
[09:16] <lifeless> jml: are you here yet?
[09:16] <wgrant> lifeless: I thought bzr didn't support that yet!
[09:16] <wgrant> Does it now?
[09:16] <lifeless> wgrant: no, but it can
[09:20] <wgrant> Heh
[09:29] <wgrant> It seems to not trigger a rescan, which is nice.
[09:44] <jtv> hi wgrant, hi lifeless
[09:44] <wgrant> Evening jtv.
[09:44] <lifeless> hi jtv
[09:45] <jtv> fosdem was fun—presentations on pgpool-II and postgres-R in particular.
[09:45]  * jelmer waves
[09:45] <jtv> hi jelmer :)
[09:45] <wgrant> Is postgres-R another replication solution?
[09:45] <jtv> Yes, but it's multi-master.
[09:46] <wgrant> Ahh.
[09:46] <wgrant> Hi jelmer.
[09:46] <jtv> Unfortunately it's not quite done yet.
[09:46] <jtv> Which is a real shame.
[09:46] <lifeless> jtv: whats its relation to -XC ?
[09:46] <jtv> None.
[09:46] <lifeless> so a different approach then ?
[09:46] <jtv> I haven't looked at -XC's architecture AFAIR
[09:47] <jtv> It's an optimistic approach, but with a centrally imposed commit order.
[09:48] <jtv> Of course recovery can be really really hard.
[09:49] <jtv> When there's a "deadlock," whichever transaction comes last breaks.
[10:02] <adeuring> wgrant: thanks for qa-ing bug 705652!
[10:02] <_mup_> Bug #705652: Make remove_translations side aware. <qa-ok> <upstream-translations-sharing> <Launchpad itself:Fix Committed by adeuring> < https://launchpad.net/bugs/705652 >
[10:05] <wgrant> adeuring: I don't know translations fantastically, so you might want to QA in detail yourself. But it seemed to work OK, from what I could see in the code and MP.
[10:31] <lifeless> mrevell: have you seen jml around?
[10:31] <mrevell> lifeless, Not yet.
[10:42] <lifeless> jml: I'll try to catch you in my morning tomorrow
[10:42] <lifeless> night all
[10:43] <Ursinha> night lifeless
[11:13] <Ursinha> is there a correct tag to use when filing checkwatches related bugs?
[11:21] <henninge> Hi Ursinha! ;-)
[11:21] <Ursinha> hi henninge :)
[11:33] <gmb> Ursinha: For checkwatches we used to use bugwatch as  a tag.
[11:33] <gmb> Also, "argh-argh-argh-stoppit-die".
[11:33] <gmb> But that one wasn't adopted as official.
[11:35] <Ursinha> hahaha
[11:35] <Ursinha> thanks gmb
[11:42] <gmb> Ahahaahahahhahahaha.
[11:43] <gmb> Windmill tests in my branch are failing because windmill isn't rendering a "Complete" element quickly enough.
[11:43] <gmb> ... Hmm. Although windmill looks different than it last did. Coincidence?
[11:48] <jtv> henninge: review done
[11:48] <henninge> jtv: thank you!
[11:48] <jtv> np
[12:02] <mpt> Huh, TIL that the RPM Package Manager uses Launchpad for feature and bug tracking
[12:03] <deryck> Morning, all.
[12:04] <gmb> Morning deryck; just the man I wanted to talk to about Windmill :)
[12:04] <deryck> ah happy way to start my day ;) :)
[12:04] <deryck> gmb, so what's up?
[12:04] <gmb> deryck: Yeah. Have you seen this before: http://pastebin.ubuntu.com/563808/
[12:05] <gmb> Looking at the code, it looks like Windmill is failing to render a "complete" element. The problem isn't LP code, it's Windmill itself.
[12:06] <deryck> gmb, no, it's the standard way Windmill fails when one of the YUI tests doesn't pass.
[12:06] <gmb> OIC.
[12:06] <deryck> gmb, you have to run the yui tests individually now to see which one failed.
[12:06] <gmb> Hahaha.
[12:06] <gmb> Joy.
[12:06] <gmb> deryck: Thanks for the "help".
[12:06] <gmb> :)
[12:07] <deryck> I've gotten Windmill to spit that out before, but I don't recall how.  I think maybe:  ./bin/test -cvvt test_yuitests --layer=BugsWindmillLayer
[12:07] <deryck> gmb, spit out the individual test failing, I mean. ^^
[12:07] <deryck> gmb, and no problem :-)
[12:07] <gmb> deryck: Right. I'll give that a shot. Thanks.
[12:19] <bigjools> stub: do you want me to add the manual debversion patch rollout step to LPS, or have you got that covered?
[12:26] <stub> bigjools: What in particular where you thinking about? debversion.sql has already been applied to production if that is what you mean.
[12:27] <bigjools> stub: sweet
[13:11] <Ronnie> lifeless: ping
[13:12] <Ursinha> Ronnie, he's gone already, I'm afraid
[13:12] <Ronnie> ok, thx Ursinha
[13:12] <Ursinha> np
[13:13] <Ronnie> wgrant: ping
[13:15] <Ronnie> im trying to figure out the interaction between LD, LP and the openId provider: http://img812.imageshack.us/img812/7037/schemaopenidld.png
[13:19] <wgrant> Ronnie: I'm not here either.
[13:19] <wgrant> However, the question mark is about right.
[13:19] <wgrant> It is a terrible hack involving partial database replication.
[13:19] <wgrant> SSO does not store team memberships or timezones, though -- it gets them from the replicated LP DB.
[13:21] <Ronnie> wgrant: does i access the LP DB each time the SREG is requested, or does it work on daily update or something?
[13:23] <wgrant> Ronnie: The team membership tables are continuously replicated to it, just as if it was a normal DB slave.
[13:23] <wgrant> So it should be up to date, at least within a couple of minutes.
[13:23] <wgrant> Normally seconds.
[13:26] <Ronnie> oke
[13:32]  * wgrant sleeps.
[14:00] <deryck> henninge, ping for standup
[14:05] <henninge> deryck: oops, sorry. Be right there.
[14:20] <gary_poster> hm.  when I try to run make schema I get "psycopg2.ProgrammingError: type "debversion" does not exist
[14:20] <gary_poster> ".    This is from db patch 40.  I don't see anything on the lists about this.
[14:20] <gary_poster> stub: ^^ ?
[14:20] <bigjools> gary_poster: you need to update your lp-deps
[14:20] <gary_poster> ah-ha thanks bigjools
[14:21] <bigjools> no prob - if this is the only problem with that branch I'm happy :)
[14:21] <gary_poster> :-)
[14:23] <statik> goooooooooood morning launchpad hackers
[14:23]  * bigjools waves at statik
[14:24] <flacoste> good morning statik
[14:24] <flacoste> back from the tropics!
[14:24] <statik> tropics are overrated, computers are more fun
[14:33] <gary_poster> :-)
[15:40] <bac> abentley: i need to land a loggerhead branch for max.  do i just use 'bzr lp-land' to land it or do i need to do anything else?
[15:41] <abentley> bac, I imagine lp-land will work, but I've never landed a loggerhead branch.
[15:41] <bac> abentley: ok, i assumed you would've.  thanks.
[15:42] <abentley> bac, are you asking whether you should do something prior to landing, or just whether lp-land will work?
[15:43] <bac> abentley: actually wondering if i need to do something post-landing.  'bzr lp-land --dry-run' looks reasonable, so i assume it will work.
[15:43] <abentley> bac, I notice the branch isn't owned by pqm, so it's likely PQM doesn't manage landings for it.
[15:44] <abentley> bac, you could ask jam since he landed the most recent changes.
[15:44] <bac> abentley: https://code.launchpad.net/~mkanat/loggerhead/launchpad/+merge/46880 -- the merge to branch is owned by pqm
[15:44] <abentley> bac, you probably just push the branch.
[15:46] <abentley> bac, okay, for that branch I'd expect lp-land to work.  Trunk isn't maintained by PQM.
[16:04] <sinzui> jml: Do you want to mumble today?
[16:18] <deryck> adeuring, hi.  Did you get a chance to look at that mail/bug/etc. that was qa related?
[16:19] <adeuring> deryck: yes; I'm right now fiugring out some qa tests
[16:19] <deryck> adeuring, ok, cool.  thanks
[16:22] <jcsackett> deryck: can i pick your brain about bug 632847 for a just a second?
[16:22] <_mup_> Bug #632847: Bug page OOPS when viewed in deactivated project context <404> <lp-bugs> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/632847 >
[16:22] <jcsackett> specifically, do you think the fix is just removing the OOPS condition, or making sure the bug link works via the (not-deactivated) other context?
[16:23]  * deryck looks at bug
[16:23] <jcsackett> i'm leaning towards the latter, but wondering if there might be precedent for the former in bug stuff.
[16:27] <deryck> jcsackett, I think we're trying to prevent people viewing deactivated projects.  So I think we shouldn't list bug tasks for dead projects.  That seems the right fix to me.
[16:28] <deryck> jcsackett, in other words, there should be no entry in the bugtask table that leads someone to want to click through to the dead project.
[16:28] <deryck> or bug list, or whatever
[16:29] <deryck> assuming the goal is to hide dead projects.  if that's not our goal (and I'm really not sure), then just make the dead project viewable with a "this is dead" notice :-)
[16:29] <sinzui> jcsackett: deryck. I agree with do not list. If we supported project deletion, we would want them deleted to. If the project is re-enabled, we expect them to show up again
[16:29] <jcsackett> right, but the task listing for the active one should work. that's a better statement of what i meant.
[16:29] <jcsackett> dig.
[16:30] <deryck> yes, right.  I think we all agree :-)
[16:30] <jcsackett> cool. thanks, deryck, sinzui.
[16:32] <sinzui> jcsackett: are you pondering what happens when you (~registry member) visits the bug for a deactivated project. Should /you/ see the bug task?
[16:33] <sinzui> Most bugs have one task. I think the page will break if there are no tasks. We may not want to fix an oops that only we can see, but that is unlikely
[16:35] <jcsackett> sinzui: i think probably ~registry members should see the bug task, but it shouldn't be listed otherwise.
[16:35] <jcsackett> for ~registry members, there isn't an OOPS. it's non ~registry folk who see the link, click it, and then get a 404 (with an OOPS).
[16:36] <sinzui> jcsackett: yes. I was pondering what would happen if we always hid the task, then we might mutate the oops to ourselves
[16:37] <jcsackett> sinzui: i think it should be reasonably easy to check if the person can see deactivated contexts, and then throw in the parameter for whether or not to also list the associated tasks.
[18:11] <lifeless> Ursinha: checkwatches I think; it should autocomplete.
[18:11] <lifeless> jml: (hopeful) ping
[18:12] <Ursinha> lifeless, it's bugwatch
[18:17] <lifeless> kk
[18:28] <jml> lifeless: hi
[18:28] <lifeless> \o/
[18:28] <lifeless> hi
[18:28] <lifeless> I'd like to nab you for a vocal catchup at a convenient time
[18:29] <lifeless> jml: ^
[18:29] <jml> lifeless: sure. later tonight ok?
[18:29] <lifeless> sure
[18:30] <lifeless> jml: I have a couple of calls with us folk, but they can probably shuffle if you can tell me when your preferred time is
[18:30] <lifeless> s/us/north american/
[18:31] <jml> lifeless: I'll get back to you about that shortly
[18:31] <lifeless> excellent, thank you
[18:34] <jcsackett> sinzui: mumble?
[18:39] <lifeless> I can has review ? https://code.launchpad.net/~lifeless/launchpad/showtimes/+merge/48754  - its not r-c, but I want to move it out of the coding lane in my head
[18:40] <lifeless> jcsackett: hi
[18:41] <jcsackett> lifeless: hello.
[18:41] <lifeless> jcsackett: I saw that you ran into a wall on bug 421901
[18:41] <_mup_> Bug #421901: Person:+bugs timeouts <lp-bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/421901 >
[18:41] <lifeless> jcsackett: I did some analysis on that in the weekend to help
[18:41] <lifeless> jcsackett: merging the union won't fix the bug that is reported - its one particular sub part that is the problem.
[18:43] <lifeless> jcsackett: separately, as something to keep in your toolbox - unions that are each highly selective can be more efficient than a very wide query - see for instance bug 714383
[18:43] <_mup_> Bug #714383: bugtask fti search is slightly faster as a union rather than combined or clause <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/714383 >
[18:44] <jcsackett> lifeless: huh. that flies in the face of anything i would expect. :-)
[18:44] <lifeless> jcsackett: sql tuning, like python, is 'best measured not guessed' :)
[18:44] <jcsackett> :-p
[18:45] <lifeless> anyhow
[18:45] <lifeless> I was hoping that narrowing the focus to changing the 'commented on' component would make bug tractable for you
[18:47] <jcsackett> lifeless: actually, it might and i may grab that again, but i needed to get out of it and do something i could get some success again on and thought i would leave it open in case someone else wanted it.
[18:47] <lifeless> jcsackett: cool
[18:48] <lifeless> jcsackett: I was checking to make sure I'd unblocked it; if/when you get back to it, if its still not helpful enough I'd be delighted to do more
[18:51] <jcsackett> lifeless: i will check it out again when i finish what i'm currently working on; if i need more data i'll definitely ping you.
[18:52]  * lifeless waggles fingers together
[18:52] <lifeless> excellent
[18:53] <lifeless> statik: hi
[18:53] <lifeless> statik: we catching up today?
[20:30] <thumper> deryck: ping
[20:30] <deryck> hi thumper
[20:31] <thumper> deryck: what's happening with lazr-js?
[20:31] <deryck> thumper, did you see my mail?
[20:31] <thumper> no
[20:31]  * thumper looks for it
[20:31] <thumper> oh found it
[20:32] <thumper> ok, thanks
[20:32] <thumper> do you need a review?
[20:34] <deryck> thumper, not yet.  Finishing one little issue.  will get it up before I leave and you can review it while I'm away if you like.
[20:36] <deryck> but it should be easy to review for someone during my am.  since we can't land it yet anyway.
[20:55] <wallyworld_> thumper: i gotta drop the kid to school early this morning. as in now :-( so i'll have to miss the standup. we can catch up later
[20:56] <thumper> wallyworld_: sure, np
[20:56] <thumper> deryck: ok
[20:56] <thumper> leonardr: ping
[20:56] <leonardr> thumper, yo
[20:57] <thumper> leonardr: care to join me in mumble?
[20:57] <leonardr> sure
[20:58] <deryck> thumper, actually EOD is on me.  I'll get this through review before your AM tomorrow, though.
[21:01] <lifeless> flacoste: skype?
[21:01] <flacoste> lifeless: yes
[21:03] <deryck> later on, everyone
[21:22] <LPCIBot> Project devel build (423): FAILURE in 6 hr 5 min: https://hudson.wedontsleep.org/job/devel/423/
[21:22] <LPCIBot> Launchpad Patch Queue Manager: [release-critical=wallyworld][r=jtv][bug=710591][incr] Provide
[21:22] <LPCIBot> TranslationMessage.acceptFromImport and
[21:22] <LPCIBot> .acceptFromUpstreamImportOnPackage.
[21:28] <wallyworld_> thumper: catch up now or later?
[21:29] <StevenK> I think he's still injecting coffee
[21:29] <wallyworld_> of course, i'm sure it's been 5 minutes since the last time :-)
[21:36] <jml> huwshimi: ping
[21:36] <huwshimi> huwshimi: Hello.
[21:37] <huwshimi> ugh
[21:37] <huwshimi> jml: Hello
[21:37] <huwshimi> how do I do that!
[21:39] <jml> huwshimi: skype?
[21:39] <huwshimi> jml: Sure
[21:45] <StevenK> wallyworld_: I wonder if thumper has started stalking his coffee maker repair man yet
[21:46] <wallyworld_> StevenK: perhaps. it seems to be taking a long time to get fixed
[22:11] <poolie> hi all
[22:13] <wgrant> Morning poolie.
[22:20] <poolie> hi wgrant
[22:20] <poolie> iirc i can get the api to send xhtml by setting the right Accept header?
[22:20] <jcsackett> sinzui: i am stumped on the best way to double check if someone is member of ~registry for the purposes of deciding to list deactivated projects. thoughts?
[22:23] <poolie> ah, application/xhtml+xml
[22:24] <sinzui> jcsackett: I think that is a role. registry_experts
[22:26] <sinzui> jcsackett: in security.py you use user.in_registry_experts or in other code you can get the team using getUtility(ILaunchpadCelebrities).registry_experts
[22:27] <jcsackett> sinzui: ah, fantastic. thanks.
[22:28] <wgrant> You can adapt to IPersonRoles to get in_registry_experts anywhere.
[22:31] <jcsackett> wgrant: cool. thanks, both. :-)
[22:32] <poolie> leonardr, hi
[22:35] <lifeless> StevenK: hi
[22:36] <lifeless> StevenK: yesterday you were looking at consolidating the recipe exception handling code
[22:36] <StevenK> lifeless: Hai
[22:36] <lifeless> StevenK: did you get a handle on that, or would you like to work through it in more detail ?
[22:36] <StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/set-recipe-text-bad-data/+merge/48853
[22:42] <lifeless> reviewed
[22:42] <leonardr> poolie, hi
[22:42] <lifeless> I've suggested an alternate protocol for signaling 'error was handled'
[22:42] <leonardr> yes, if you pretend to be a web browser the web service will send you xhtml
[22:43] <lifeless> what you have will work; I think what I suggest would be simpler.
[22:43] <StevenK> lifeless: I wasn't asking for one, but thanks
[22:44] <lifeless> I figured having read it I may as well :)
[22:44] <StevenK> lifeless: What do you mean 'only accept *args' ?
[22:44] <lifeless> StevenK: the normal idiom for functions like this in python is
[22:44] <lifeless> def foo(its, params, callable, *args, **kwargs):
[22:45] <lifeless> but you've got **kwargs missing, which is surprising, so worth a note about why (or perhaps just fix)
[22:49] <wgrant> :( nightly.sh ran yesterday
[22:49] <wgrant> So the new shiny one won't run today :(
[22:55] <poolie> i just added a new official tag and it's not showing up in the official tags portal
[22:55] <poolie> is that a bug?
[22:56] <wgrant> We have no cache invalidation mechanism.
[22:56] <poolie> it's cached and not invalidated?
[22:57] <wgrant> I thought that was cached. Let me check.
[22:58] <wgrant> Yeah, cached publicly for an hour.
[23:03] <StevenK> lifeless: http://pastebin.ubuntu.com/564126/ was what you were thinking?
[23:07] <lifeless> StevenK: and remove the ret variable entirely
[23:07] <poolie> flacoste, https://bugs.launchpad.net/bugs/714414
[23:07] <_mup_> Bug #714414: unstack debian sid branches <code-hosting> <stacking> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/714414 >
[23:07] <lifeless> StevenK: you can just return it directly
[23:08] <StevenK> return callable ... ?
[23:08] <StevenK> Well, duh :-)
[23:08] <lifeless> StevenK: and you don't need one raise per except
[23:08] <lifeless> StevenK: just put one raise at the bottom of the method
[23:09] <StevenK> lifeless: Anything else?
[23:09] <lifeless> StevenK: also, one minor thing is that you need to do 'raise ErrorHandled()' - note the brackets.
[23:10] <lifeless> StevenK: I think you had two calls to error_handled to update
[23:10] <StevenK> lifeless: I thought I did those ...
[23:12] <lifeless> StevenK: push the branch, I'll eyeball for you
[23:12]  * StevenK checks he hasn't broken the tests while making tea
[23:13] <poolie> wgrant, thanks, https://bugs.edge.launchpad.net/launchpad/+bug/714901
[23:13] <_mup_> Bug #714901: updates to official bug tags not visible because of stale cached tags portlet <bug-tags> <bugs> <confusing-ui> <memcached> <Launchpad itself:Triaged> < https://launchpad.net/bugs/714901 >
[23:13]  * poolie should get rid of bookmarks to edge
[23:14] <poolie> wgrant, thanks for taking 714414
[23:15] <wgrant> poolie: I have the script, but it needs testing and landing.
[23:17] <maxb> firefox has a very useful "forget history for this host" buried in the manager dialog
[23:17] <wgrant> poolie: Has package-import been taught about wheezy yet?
[23:19] <lifeless> wgrant: I thought we were restarting it ?
[23:19] <poolie> wgrant, not yet
[23:19] <wgrant> lifeless: It needs to be taught about wheezy first.
[23:20] <wgrant> Or it will see the new wheezy pubs that gina imported this morning, and ignore them because wheezy isn't a valid series.
[23:35] <StevenK> lifeless: Changes pushed, diff updated.
[23:37] <lifeless> StevenK: oh, btw you don't need the super() call
[23:37] <lifeless> I totally glitched on that
[23:37] <lifeless> you're not upcalling, you're side calling
[23:37] <StevenK> lifeless: But it's in a superclass?
[23:37] <lifeless> does'nt matter
[23:37] <lifeless> it would matter if you wanted that *specific* variant
[23:37] <StevenK> Okay, let me change that
[23:37] <lifeless> but there are no variants, and if there were you'd want the one in your class
[23:38] <lifeless> self.error_handler
[23:38] <lifeless> self.error_handler(..)
[23:38] <lifeless> yes, that all looks good.
[23:38] <lifeless> one final suggestion would be s/error_handler/recipe_error_handler/
[23:39] <StevenK> Rargh, I just reflowed stuff due to the method call being short
[23:39]  * StevenK waves his arms at lifeless
[23:41]  * lifeless waves back
[23:46] <wgrant> poolie: Are we going to turn the package importer on before we unstack sid?
[23:47] <lifeless> wgrant: I think you should
[23:47] <lifeless> unstacking is orthogonal
[23:48] <wgrant> It's not entirely orthogonal until bzr has a GC.
[23:48] <lifeless> wgrant: sure it is; you're going to unstack sid, which will have /zero/ impact on the revisions present in the basis for wheezy branches.
[23:48] <lifeless> wgrant: because the unstack will fetch them into the sid branches if they are in sids current dependency
[23:48] <wgrant> lifeless: Is stacking transitive?
[23:49] <lifeless> wgrant: yez
[23:49] <lifeless> yes
[23:49] <lifeless> the only thing I can see going wrong is something in squeeze that sid doesn't reference - a dead head - that wheezy then references.
[23:50] <wgrant> Ohh. I had always understood that it stacked on a branch's repo, not the whole branch.
[23:51] <lifeless> the branch contains the pointer
[23:51] <StevenK> I can't see that happening -- if something isn't in sid, then it almostly certainly isn't in wheezy
[23:51] <lifeless> it points to another branch
[23:51] <wgrant> lifeless: Right, but I basically assumed it would just look for whatever repo was there.
[23:51] <lifeless> at runtime the chain of branches is loaded and a composite repository with (however many) extra revision sources is assembled
[23:52] <wgrant> Not follow further stacking references.
[23:52] <wgrant> Right.
[23:52] <wgrant> StevenK: Hmm? Why not?
[23:52] <wgrant> StevenK: wheezy is a copy of squeeze
[23:52] <wgrant> anything from t-p-u will be in wheezy but not sid.
[23:52] <lifeless> it has to follow branches, because otherwise the repository it found there would be broken
[23:52] <StevenK> Sorry, I was thinking source package names only
[23:53] <wgrant> This is a major problem.
[23:57] <wgrant> Ugh.
[23:59] <wgrant> lifeless: Can you see a way to work around this? Unless when we unstack sid we also pull the missing revs into the repo of things stacked on it..