[00:15] <rick_h> lifeless: looks like it is my work. will fix that up
[00:16] <StevenK> rick_h: So, Sidnei explained himself, and I've rejected my convoy MP.
[00:16] <StevenK> rick_h: So I'll be sorting out combo-url today, after I fix a critical regression. That I caused. :-(
[00:16] <rick_h> StevenK: yea, saw that. Does his stuff work then?
[00:17] <rick_h> StevenK: ouch, gotcha
[00:17] <StevenK> Seems to, yes.
[00:17] <rick_h> StevenK: cool, very nice then
[00:17] <lifeless> StevenK: for my edification, whats the MP url ?
[00:18] <StevenK> lifeless: Which MP?
[00:18] <lifeless> the convey one
[00:18] <lifeless> I'd like to see what sidnei has proposed
[00:18] <rick_h> lifeless: https://code.launchpad.net/~stevenk/convoy/exportable-app
[00:19] <rick_h> he's right, I should have seen it, but got hung up on the wsgi callable args
[00:19] <StevenK>     root = environ.get('CONVOY_ROOT', '/srv/launchpad.dev/convoy')
[00:19] <rick_h> Sorry I led you around the fence there StevenK
[00:19] <StevenK>     app = combo_app(root)
[00:19] <StevenK>     return app(environ, start_response)
[00:19] <StevenK> That ^ works
[00:19] <rick_h> right
[00:20] <lifeless> heh
[00:21] <StevenK> rick_h: I'll be splitting the setup.py changes into a seperate MP, but they are only a would be nice.
[00:22] <wallyworld> sinzui: i'm having trouble reproducing the badge issue on lp.dev. i created a private bug, linked to a branch, assigned bug to foo, in a separate browser logged in as foo, went to code page, and badges were visible. i restarted lp and badges were still visible
[00:22] <wgrant> wallyworld: foo being name16, the admin?
[00:22] <wallyworld> no, name12
[00:22] <wgrant> Hmm
[00:22] <wgrant> What about no-priv?
[00:22] <wallyworld> let me try
[00:23] <wgrant> name12 does have some privs.
[00:23] <wgrant> owns some projects, IIRC
[00:23] <wgrant> May even be in ubuntu-team
[00:23] <rick_h> StevenK: cool
[00:24] <wallyworld> wgrant: sinzui: assigning to no-priv seems to reproduce it
[00:24] <wallyworld> wgrant: btw, what happened to the password when logging in on lp.dev?
[00:26] <wgrant> wallyworld: I deleted passwords
[00:26] <wgrant> LP doesn't know about passwords any more.
[00:26] <wgrant> So I removed the field.
[00:27] <StevenK> And deleted the code. \o/
[00:27] <wgrant> And DB tables.
[00:27] <wallyworld> ok. so sso is the service that prompts for pw?
[00:27] <StevenK> On prod? Yes
[00:27] <wgrant> Yep
[00:28] <wgrant> LP's AccountPassword table has been sitting around with old data since April 2010.
[00:28] <wgrant> Basic auth even still worked with the old passwords :)
[00:50] <wallyworld> sinzui: found the issue. added comment on the bug
[01:36] <sinzui> wallyworld, great news. Thank you for taking a look into the issue.
[01:36] <wallyworld> sinzui: np. it's all a mess - there's duplicated code that "does the same thing" from 2007 and 2009
[01:37] <sinzui> You get to delete lines. We should get karma for deleting lines of code instead of adding features
[01:37] <wallyworld> sinzui: i have a fix and test i could land but i think i'll delete the dup code. i'm worries about the sql though since one codebase uses permissions and the other direct queries. i'll look into it
[01:40]  * wallyworld has just got a call from the mechanic - have to pop out to get car looked at 
[02:34] <StevenK> wgrant: Hai. I *think* I have it working. Would you mind eyeballing my diff?
[02:37] <StevenK> How does this even work? The mutator method isn't on the model.
[02:37] <wgrant> StevenK: The mutator method is on the model...
[02:38] <StevenK> I've declared it on the interface, with the decrations.
[02:38] <wgrant> You declare it there, but the method itself is on the model.
[02:39] <StevenK> Right. What I'm saying is my test passes, but I haven't even written the method yet.
[02:39] <lifeless> StevenK: I think wgrant is trying to say 'interface methods never ever ever actually get called'
[02:39] <StevenK> Perhaps the set_attributes="visibility" is wrong wrong wrong.
[02:40] <wgrant> StevenK: The mutator is to prevent unauthorized transitions.
[02:40] <StevenK> wgrant: http://pastebin.ubuntu.com/833450/
[02:41] <wgrant> StevenK: Right. I would add visibility to IPersonEditRestricted.
[02:42] <wgrant> StevenK: And add a test to confirm that a mortal without commercial subs can't set the visibility through the API.
[02:43] <wgrant> Erm, no, not that interface
[02:43] <wgrant> Do it however the rest of the launchpad.Edit-write-restricted attributes are done.
[02:46] <StevenK> I thought that was IPersonEditRestricted
[02:46] <wgrant> Maybe it is.
[02:55] <StevenK> from lp.services.verification.model.logintoken import LoginToken
[02:55]  * StevenK glares at his mouse
[03:26]  * wgrant banishes bug search to a separate module.
[03:28] <StevenK> Could you perhaps banish it to something outside of the code base?
[03:31] <nigelb> heh
[04:09] <StevenK> wgrant: http://pastebin.ubuntu.com/833507/ is what I have so far, but it doesn't allow anyone to check visibility
[04:21] <wgrant> StevenK: Looks like a good start
[04:21] <wgrant> Ah, Launchpad.
[04:21] <wgrant> IBugTask has three methods which do similar but not quite the same thing for different targets: getStatusCountsForProductSeries getBugCountsForPackages getOpenBugTasksPerProduct
[04:34] <james_w> http://lpqateam.canonical.com/qa-reports/deployment-stable.html looks rather odd, are parts not updating>?
[04:35] <wgrant> james_w: What's odd?
[04:36] <james_w> it's saying that a revision can be deployed that already has
[04:36] <james_w> and that an undeployable revision has been deployed?
[04:36] <wgrant> Right, that's the last revision that can be deployed.
[04:36] <wgrant> Deployed to qastaging, yes.
[04:36] <james_w> or is qastaging not the target?
[04:36] <wgrant> That page shows things that are on qastaging but not on production.
[04:36] <james_w> ah, ok
[04:37] <wgrant> qastaging automatically updates about 40 minutes after buildbot blesses a devel revision.
[04:37] <james_w> "Revision 14747 can be deployed to production." is what started my confusion
[04:37] <james_w> it looks like 14747 is *already* deployed to production?
[04:37] <wgrant> Right.
[04:38] <wgrant> But it also can be deployed :)
[04:38] <james_w> ok :-)
[04:39] <james_w> do you know where the code for this lives?
[04:39] <wgrant> lp:qa-tagger
[04:39] <james_w> thanks
[05:28] <wallyworld> lifeless: would you be adverse to me adding a permission "launchpad.CommercialSubscriber"?
[05:32] <wgrant> wallyworld: That's not needed here.
[05:32] <wgrant> wallyworld: Since you have project scope to work with.
[05:33] <wgrant> launchpad.Edit with a mutator checking that there is a commercial subscription is fine.
[05:33] <wallyworld> wgrant: we currently have a declarative permission check on that field for launchpad.Moderate. seems like a good  practice
[05:34] <wgrant> It also doesn't really scale, as we see here.
[05:34] <wallyworld> declarative security = good
[05:34] <wallyworld> i'm sure we can find other usages for the new permission
[05:35] <wgrant> Yes, declarative security is good.
[05:35] <wallyworld> instead of hard coding rules everywhere
[05:35] <wgrant> But not in the current style we have.
[05:35] <wallyworld> not sure i understand your objection?
[05:36] <wgrant> Having to define new global permissions is a bit icky.
[05:36] <wallyworld> why?
[05:36] <wgrant> Because we end up with stuff with three subtly conflicting meanings, like launchpad.Moderate.
[05:37] <wallyworld> the meaning is pretty well documented in permissions.zcml
[05:37] <wgrant> Heh
[05:38] <wallyworld> my view at the moment is that we have too many permission checking bits of code scattered everywhere
[05:38] <wallyworld> and i don't want to add another
[05:39] <wallyworld> the bug i fixed this morning was due to this sort of thing
[05:39] <wallyworld> so if i have to add something, i wanted it to be done using our current security framework
[05:39] <wgrant> We don't have a security framework..
[05:39] <wallyworld> we do - it's provided by zope
[05:39] <wgrant> The one we inherit from Zope is not suitable for our purposes.
[05:42] <wallyworld> seems to be doing ok for now - it functions, no? may not be perfect but it's what we have
[05:46] <wgrant> Huh?
[05:46] <wallyworld> so i'd rather stick to that than adding new stuff
[05:46] <wgrant> We work around it in tonnes of places.
[05:46] <wgrant> For this sort of thing.
[05:46] <lifeless> wallyworld: bug this morning ?
[05:46] <lifeless> wallyworld: the merge proposal one ?
[05:46] <wallyworld> lifeless: the bug badges one
[05:46] <lifeless> wallyworld: bug # ?
[05:46]  * wallyworld looks
[05:46] <wallyworld> bug 741234
[05:46] <_mup_> Bug #741234: product:+code-index merge proposal queries do not show private bugs visible by assignment <disclosure> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/741234 >
[05:46] <lifeless> ok
[05:46] <lifeless> so that has nothing to do with declaritive security
[05:46] <lifeless> and everything to do with querying too restrictively - duplication of code yes
[05:46] <wallyworld> i meant that it had to do with bits of security code scattered everyehrre
[05:46] <wallyworld> and delarative security helps avoid that
[05:46] <lifeless> mmm
[05:46] <wgrant> It can't avoid that.
[05:46] <lifeless> so there is a layering confusion in this discussion
[05:46] <wgrant> This is exactly the sort of thing that cannot be done with anything like the Zope security framework that we inherit.
[05:46] <lifeless> the DB layer, unless we model *everything* [and thus don't need any zope security framework stuff] cannot implement all business rules.
[05:46] <lifeless> The app server layer, unless the DB returns *only* the right stuff, cannot validate and serve content quickly, unless they hold all objects in memory all the time [more-or-less, and close enough for the purpose of this discussion]
[05:46] <lifeless> today, we neither model everything (e.g. the appservers do not impersonate the user who made the request - the DB does not know about users and cannot enforce update business logic like 'bug supervisors can set this enum')
[05:46] <lifeless> nor can we hold everything in memory in every appserver process
[05:46] <wallyworld> agree with all that
[05:46] <wallyworld> the issue at hand - we have a field protected in zcml by a declarative permission. i want to change that to a new one
[05:46] <lifeless> -> we have two entirely different layers, which need entirely different implementations even though there are many rules which will occur at both levels
[05:46] <lifeless> wallyworld: ok, well I went on this tangent when you used the bug this morning as a symptom of what you're dealing with this afternoon :P You can understand my confusion?
[05:47] <lifeless> wallyworld: what are you working on this afternoon ?
[05:47] <wallyworld> lifeless: sure, sorry. i was merely trying to illustrate a point
[05:47] <wallyworld> bug 885503
[05:47] <_mup_> Bug #885503: Its not obvious on the UI how to choose to have all bugs reported against your project marked private by default. <bugtracker> <disclosure> <documentation> <privacy> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/885503 >
[05:47] <wallyworld> the private_bugs field is protected by launchpad.Moderate
[05:47] <lifeless> wallyworld: I'm horribly detail orientated - sorry!
[05:48] <wallyworld> i was thinking about using a new permission launchpad.CommercialSubscriber
[05:48] <wallyworld> since that's what defines the editablity of that field once the bug is fixed
[05:48] <wallyworld> or i could use a mutator like wgrant suggested but i didn;t want to do that
[05:48] <lifeless> so, your logic here is 'add a new rule saying 'members of commercialsubscribers get commercialsubscriber on the product configuration'
[05:49] <wgrant> The editability of the field is defined by (user holds launchpad.Edit on project + project has commercial subscription)
[05:49] <lifeless> s/logic/proposed solution/
[05:49] <wallyworld> i was also thinking we could use the permission elsewhere
[05:49] <wallyworld> not sure where right now... but
[05:50] <lifeless> so, AIUI the zope way of doing this is to only grante Moderate to the field for the right folk
[05:50] <lifeless> e.g. its just granted too leniently atm
[05:50] <wallyworld> or too restrictive
[05:50] <lifeless> and probably you'd end up factoring out a separate object so that the granularity of the permission system would allow custom rules for that field(s)
[05:50] <wallyworld> since we want to allow folks other than registry and admin
[05:51] <lifeless> specifically, permissions *should not* reflect 'combination of rules' - they should reflect 'allowed to do X'
[05:51] <lifeless> so yes, I object.
[05:51] <lifeless> it doesn't fit with the zope security model
[05:51] <lifeless> (AIUI)
[05:51] <wallyworld> np, thanks for the input
[05:52] <wallyworld> gotta fly out and get the kid from school - it's just started to piss down rain here
[05:52] <wgrant> wallyworld: I complete share your concerns about security code being everywhere.
[05:52] <lifeless> the /adapters/ that grant moderate for objects of IFoo - thats where there rules, and combinations of rules, are meant to live
[05:52] <wgrant> But I don't think we should shoehorn everything into the Zope model.
[05:52] <wgrant> Because we've seen it simply doesn't work.
[05:52] <lifeless> so I'd rephrase the problem as 'why isn't lp.Moderate being granted to $user on $field' and chain back.
[05:53] <lifeless> we may find the zope model isn't granular enough, and we can look at how to deal with that
[05:53] <lifeless> wallyworld: ciao, chat later
[05:53] <wallyworld> lifeless: i haven't looked where else moderate is used, don't think chaining will necessarily work perhaps
[05:54] <wallyworld> talk later
[05:56] <wgrant> lifeless: Max heat demolition has landed.
[05:56] <wgrant> lifeless: I'll land the aging removal tomorrow once these get through to db-stable.
[06:09] <stub> Anyone know if there is a workaround to this ec2 land error? https://pastebin.canonical.com/59669/
[06:12] <stub> Think it is because the branch is owned by a team, not a person
[06:13] <wgrant> stub: You'll have to either hack it or ec2 test and lp-land manually.
[06:14] <stub> Yer, looks like a trivial fix. Just one more thing to sort before actually landing what I wanted to land :)
[06:18] <stub> But of course, I only need the fix locally to use it and can land later.
[07:36] <lifeless> wgrant: cool
[07:37] <lifeless> wgrant: btw what was the change from max heat to bug count - I saw a reference fly by but didn't look into it
[07:43] <wgrant> lifeless: The ordering on DistroSeries:+needs-packaging
[07:44] <wgrant> ie. nobodycares
[07:44] <wgrant> Sort of like hardware bug searches.
[07:44] <wgrant> Tag sorting.
[07:44] <wgrant> Blueprint sorting.
[07:45] <wgrant> Except those three are a little harder to remove without people noticing.
[07:49] <stub> Is it my imagination, or are ec2 errors 'psycopg2.OperationalError: FATAL:  could not open relation mapping file "global/pg_filenode.map": No such file or directory' rather common?
[07:49] <wgrant> I've had approximately two of them ever.
[07:49] <stub> db setup must be failing, or ram disk being full or something?
[07:49] <stub> hmm...
[08:13] <stub> oh... think it is picking up my PG9.1 image rather than the 8.4 image
[08:14]  * stub gets explicit
[08:54] <lifeless> wgrant: e.g. sortbypopcon would be win
[08:55] <adeuring> good morning
[08:55] <wgrant> lifeless: If we had it :)
[08:55] <wgrant> But LP doesn't really consume.
[08:55] <wgrant> It subsumes :(
[10:08] <StevenK> gmb: Bwahahaha at your Churchill comment on FB.
[11:18] <StevenK> adeuring: If you QA r14748 and r14755 we can probably deploy
[11:19] <adeuring> StevenK: ah,. ok, let me look...
[11:33] <rick_h> morning party people
[11:44] <adeuring> StevenK: done
[13:31] <rick_h> adeuring: can you do me a fav and peek at this really quick? https://code.launchpad.net/~rharding/launchpad/graph_lpjs_928500/+merge/92024
[13:31] <adeuring> rick_h: sure
[13:31] <rick_h> ty, very small but want to get it going
[13:34] <adeuring> rick_h: looks good. thanks for this fast fix!
[13:35] <rick_h> adeuring: ty
[13:39] <rick_h> bah, anyone seen broken ec2 land in get_stakeholder_emails in autoload.py?
[13:49] <rick_h> nvm, found it, bug https://bugs.launchpad.net/launchpad/+bug/928853 in case anyone hits it
[13:49] <_mup_> Bug #928853: ec2 land fails if there is no None value in the stakeholder email set <ec2> <land> <Launchpad itself:Triaged> < https://launchpad.net/bugs/928853 >
[14:03] <rick_h> adeuring: another one please if you have a sec, sorry https://code.launchpad.net/~rharding/launchpad/ec2_land_928853/+merge/92033
[14:03] <adeuring> rick_h: sure, np
[14:04] <adeuring> rick_h: r=me.
[14:04] <rick_h> adeuring: ty
[14:05] <wallyworld_> jcsackett: hi, there's only one way to figure out what badges to show - i removed the duplicate code
[14:06] <jcsackett> wallyworld_: i only see you removing the bug badge code; BranchBadges still exists, as does HasBadges &c.
[14:06] <jcsackett> wallyworld_: i was referring to the problem that over all of LP we now have multiple ways of doing things--which isn't a problem you introduced, it clearly already existed.
[14:07] <wallyworld_> from memory HasBadges is a base class/interface and the code in branchlisting uses BranchBadges/HasBadges to do it's work, but now there's only the one way of doing it
[14:08] <wallyworld_> it's a bit convoluted, but there is only the one code path
[14:08] <jcsackett> wallyworld_: ok.
[14:08] <wallyworld_> it's a bit hard to explain on irc - i'll fill you in on the standup
[14:08] <jcsackett> wallyworld_: i won't be at tonight's standup. we'll have to discuss at the next one. but please do fill me in. :-)
[14:09] <jcsackett> thanks again for solving that bug. good to know that i was just looking in an entirely the wrong place. :-)
[14:09] <wallyworld_> will do. i'm fairly sure i'm correct in my assertion but still i may have made a mistake. it was a lot clearer in my mind several hours ago when i did it
[14:10] <wallyworld_> np. i can see where the confusion crept in - there we 2 methods to determine whether to show bug badges
[14:10] <wallyworld_> and one was never called by the view code
[14:10] <wallyworld_> hence your test passed but it still failed in practice
[14:11] <wallyworld_> there pseudo dup code was done in 2007 and in 2009
[14:11] <wallyworld_> so i deleted the 2nd way (which was inferior anyway since it made one sql per linked bug)
[14:12] <wallyworld_> and now there's a single method that is invoked when the branch listing renders and i reimplemented it to re-used the bug privacy filter stuff instead of doing it's own thing
[14:13] <wallyworld_> which was the real root cause here
[14:13] <wallyworld_> ie duplicated (but not) bug visibility code
[14:13] <wallyworld_> messy
[14:32] <deryck> adeuring, abentley -- reminder that standup is G+.  I sent invites.
[14:46] <deryck> abentley, adeuring, rick_h -- ah, one more thing, I will take lunch offline so I can get back into my gym routine and relocate to Wendy's shop.
[14:46] <adeuring> ok
[14:46] <rick_h> deryck: good stuff, go kill the treadmill
[14:49] <deryck> rick_h, it usually is the one doing the killing.
[15:09] <abentley> sinzui: I have pocketlint 0.5.27-0gdp410~oneiric1 installed, and it's broken with doctests.  Known issue?
[15:10] <sinzui> abentley, no. please report a bug at https://bugs.launchpad.net/pocket-lint so that I can get a fix in today
[15:13] <abentley> sinzui: bug #928903
[15:13] <_mup_> Bug #928903: Pocketlint is broken with doctests <pocket-lint:New> < https://launchpad.net/bugs/928903 >
[15:14] <sinzui> abentley, I might have this fixed in the hour. I need to save my blog post first
[15:25] <abentley> adeuring: Could you do a review for me?  It's a one-liner.  https://code.launchpad.net/~abentley/launchpad/stable-test-failures2/+merge/92047
[15:27] <adeuring> abentley: sure
[15:27] <abentley> adeuring: thanks.
[15:28] <adeuring> abentley: r=me
[15:35] <abentley> rick_h: know anything about jsbuild failures?  http://pastebin.ubuntu.com/834010/
[15:36] <rick_h> abentley: looking
[15:36] <rick_h> abentley: is this off devel? /me looks if the combo stuff from SteveK landed
[15:37] <abentley> rick_h: This is off stable.
[15:37] <abentley> rick_h: r14759
[15:38] <rick_h> abentley: make clean? I'm not seeing that locally
[15:40] <abentley> rick_h: That works, but if I delete build/js/yui/yui-3.3.0/yui/yui.js it breaks again.
[15:40] <rick_h> abentley: ok, SteveK has a branch that redoes how that build stuff works that should be coming really soon
[15:41] <rick_h> it's been reviewed
[15:41] <abentley> rick_h: cool.
[15:41] <rick_h> abentley: so if it's ok, we'll just think to test it once it lands
[15:42] <abentley> rick_h: Sure.
[16:20] <sinzui> abentley, pocket-lint is fixed, you will get the package in about 4 hours
[16:21] <abentley> sinzui: Thanks!
[19:07] <salgado> lifeless, do you want to talk about our plans for work-items in LP or are you happy with what we described on the mailing list?
[19:11] <sinzui> salgado, I believe lifeless is dismantling a droid to get a message to General Poster about the plan for the death star
[19:14] <salgado> heh
[19:27] <lifeless> salgado: I would enjoy chatting about it, but you shouldn't block on us talking; I've got no timeslots today but perhaps tomorrow (you can check my google calendar)
[19:31] <lifeless> rick_h: btw
[19:31] <lifeless> rick_h: talking of template engines, handlebarsjs.com is horribly misleading vs the actual handlebars.js git repo. (e.g. examples that don't work ...)
[19:32] <rick_h> lifeless: :( sucky.
[19:33] <lifeless> meh, its advertising site
[19:33] <lifeless> I tried an experiment, and found errors on the site, so went 'wtf'?!?!?!
[19:33] <lifeless> (also note the total lack of contact details >< hard to file a bug...
[19:33] <rick_h> yea, that's beyond annoying when the main examples don't work
[19:34] <lifeless> rick_h: the example 'Handlebars HTML-escapes values returned by a {{expression}}. If you don't want' ... is the first (perhaps only) one that was wonky
[19:34] <lifeless> a vs A
[19:34] <lifeless> small thing, but quite disappointing
[19:34]  * rick_h is now curious how different Y.Handlebars might be from the git repo
[19:34] <rick_h> I've not tracked how the pulling in has gone from the YUI side
[19:35] <lifeless> I'd be interested to know, it has some bearing on my experiment
[19:35] <lifeless> as does the breadth of features yui itself uses from within handlebars
[19:37] <rick_h> lifeless: right, I'll check that out. I'm curious now. The framework isn't using much, but my understanding is that they're using for internal/public apps that should be working it a bit
[19:37] <rick_h> but not sure which apps have it so I'll ask/check
[19:39] <rick_h> lifeless: https://pastebin.canonical.com/59772/
[19:39] <rick_h> lifeless: basically any file in that dir yui- is yui customizations, some api docs, tweaks
[19:40] <lifeless> thanks
[19:40] <lifeless> what channel is that ?
[19:40] <rick_h> #yui
[19:45] <rockstar> rick_h, handlebars and Y.Handlebars are not different
[19:45] <rockstar> rick_h, are you using 3.5pr2 currently?
[19:45] <rick_h> rockstar: on an outside app yea. I'm trying to talk lifeless into handlebars for our stuff
[19:46]  * rick_h hates mustache with the heat of many pizza ovens
[19:46] <rick_h> :)
[19:46] <rick_h> rockstar: you guys playing with it?
[19:46] <rockstar> rick_h, we've been using Y.substitute still
[19:46] <rick_h> ah ok
[19:46] <rockstar> rick_h, your loader code that you stole from us won't run in its current form on 3.5
[19:46] <rick_h> rockstar: I'm not using most of it
[19:47] <rick_h> only stole some basics on generating the module config
[19:47] <rockstar> Why do you need handlebars currently?
[19:47] <rick_h> we've got mustache and not happy with it
[19:47] <rockstar> What are you not happy with?
[19:47] <rick_h> but it has a python version which is why it won
[19:47] <rick_h> really poor performance, lack of building decent helpers/modules
[19:47] <rick_h> and very buggy from python -> js versions
[19:47] <rockstar> Oh, so apparently you're doing templating somewhere other than the browser as well?
[19:48] <rick_h> rockstar: yea, the new buglisting is mustache on server/client
[19:48] <rick_h> the first load is server generated and the subsequent are client
[19:49] <rick_h> right, so the dicussion is can we implement a python version of handlebars and use it client side and solve a lot of issues
[19:49] <rick_h> or does fixing mustache make sense
[19:49] <rick_h> or something else entirely
[19:49] <rick_h> but LP is getting waaaay to many ways to build a tpl
[19:49] <rockstar> Yeah, I bet.
[19:50] <rick_h> the fact that we're YUI and YUI is bringing in handlebars is a BIG plus imo
[19:50] <rockstar> Absolutely.
[19:50] <lifeless> rockstar: we still have use cases around filing bugs etc from stone age (text) browsers
[19:50] <rockstar> lifeless, yeah, and U1 doesn't worry about those browsers.
[19:51] <lifeless> rockstar: which is a bit sad; also for google juice you still need server rendered content
[19:51] <rockstar> But we also aren't TOO concerned about duplicating templates slightly.
[19:51] <beuno> lifeless, not for private content you don't  :)
[19:51] <rick_h> I still think there's a way around that using normal "google, don't index this...but go look here" for that
[19:51] <lifeless> beuno: actually you do
[19:51] <lifeless> beuno: search appliance
[19:52] <beuno> lifeless, we don't do search appliance, but yes, that would be a use case
[19:52] <lifeless> rick_h: there is, the way it works is you point google at server rendered pages using a site map
[19:52] <rockstar> rick_h, yeah, google has a hashbang protocol
[19:52] <lifeless> beuno: canonical has one internally
[19:52] <rockstar> But javascript only is not great for accessibility
[19:52] <rick_h> yea, that's very true
[19:52] <rockstar> Or, rather, it misses a11y in many core cases
[19:52] <lifeless> so, long story short, I don't think we can justify client only rendering yet, all things considered.
[19:53] <lifeless> but we don't want to pay through the nose for doing both, nor do we want to only do client in a few cases
[19:53] <rockstar> I don't think you *should* justify client only rendering
[19:53] <rockstar> Ever.
[19:53] <lifeless> rockstar: my personal jury is still out on that; call me on the fence with a lean towards server-side-needed-indefinitely
[19:54] <lifeless> I do think we should separate the layers
[19:54] <lifeless> data layer <-> template layer <-> HTTP HERE
[19:54] <rockstar> lifeless, yeah, I'd be happy to chat about that sometime and kick you off the fence.
[19:54] <lifeless> and client rendering can possibly suck straight from the data layer
[19:54] <lifeless> rockstar: which side do you want me to land on ?
[19:54] <rick_h> hah
[19:54] <rockstar> lifeless, server-side-needed-indefinitely
[19:55] <lifeless> :) so as I say I'm bent that way as it stands
[19:55] <rockstar> :)
[19:55] <lifeless> but its worth reevaluating regularly
[19:55] <beuno> don't ruin the surprise!
[19:55] <rockstar> Screen readers force us into perpetual IE6 support. :)
[19:56] <rick_h> you guys are sending the end of my day into depression
[19:56] <mwhudson> it's just a trick to make you stay working later
[19:56] <lifeless> rockstar: we just blew IE6 away
[19:56] <lifeless> rockstar: so gnar gnar gnar :P
[19:56] <rockstar> Yeah, we did that too (and IE7 as well), but if you care about a11y, you still have to *kinda* support it.
[19:56] <rockstar> Screen readers don't care about bleeding edge.
[19:57] <lifeless> We can ship out cd's more cheaply.
[19:57] <rick_h> what are our stats on that stuff? Is that out there to see?
[19:57] <rick_h> not to minimize the issue at all, just curious
[19:57] <lifeless> we have *200* data types in LP, supporting something awkward across the board is very expensive
[19:57] <lifeless> rick_h: stats on which stuff?
[19:58] <rick_h> browser/screen reader/etc
[19:58] <rockstar> rick_h, how do you get stats on browser plugins?
[19:58] <rick_h> I'd assumed that the screen readers would alter UA?
[19:58] <rick_h> I guess I've never actually used/seen used one
[19:58] <lifeless> rick_h: chat to TheMuso
[19:59] <lifeless> rick_h: he's one of our blind staff
[19:59] <rockstar> rick_h, go make a blind friend.  That's what I did.
[19:59] <rick_h> k
[19:59] <rockstar> I mean, chat with TheMuso as well, but have someone you can meet for lunch.
[19:59] <lifeless> he'll be in #canonical in a couple hours
[19:59] <rick_h> I'll put out a personal ad in the area :)
[19:59] <rockstar> Seeing the crap impaired sight people deal with makes my heart hurt.
[20:00] <rick_h> lifeless: so this guys in #yui gave me this for some handlebar exapmles: http://beta.tdp.me/static/scripts/bundle.js http://beta.tdp.me
[20:00] <rick_h> lifeless: says he's using some self build block helpers and such
[20:01] <rick_h> to give you stuff to poke at
[20:01] <rick_h> lifeless: so do you have stuff with the server side making api calls to services so it can server side process it?
[20:01] <rick_h> sorry, meant rockstar ^
[20:07] <bryceh> sounds like it's affecting a few people - https://bugs.launchpad.net/ubuntu/+source/python-launchpadlib/+bug/929068
[20:07] <_mup_> Bug #929068: [Precise] bug_task.date_created is returning 'unicode' objects instead of 'datetime' objects <amd64> <apport-bug> <precise> <running-unity> <python-launchpadlib (Ubuntu):New> < https://launchpad.net/bugs/929068 >
[20:12] <abentley> lifeless: After updating sourcedeps.conf, update-sourcecode will update sourcedeps.cache for you.  Please commit that.
[20:17] <lifeless> abentley: it still works if it is stale, right ?
[20:17] <abentley> lifeless: Yes, it's just slower.
[20:18] <lifeless> abentley: I did that particular change in an environment where update-sourcecode won't work [long story], which is why I didn't have the cache updated
[20:18] <abentley> lifeless: Ah.
[20:19] <james_w> bryceh, bug 924240 looks to be the same
[20:19] <_mup_> Bug #924240: datetime interpretation changed <wadllib:Triaged> < https://launchpad.net/bugs/924240 >
[20:23] <lifeless> statik: can we move our 1:1 up (to ~now ?)
 well, wadllib could do something like that
 try downgrading it?
 hah
 python-wadllib_1.2.0+ds-2build1_all.deb
 indeed it works
[20:25] <statik> lifeless: yes! better for my schedule also
[20:25] <lifeless> skype? g+? pots? pigeons?
[20:26] <statik> lifeless: g+? https://plus.google.com/hangouts/extras/canonical.com/statik-hangout
[20:28] <lifeless> I'll start one - that wants me to activate my canonical address as a profile
[20:28] <lifeless> ETOOMANYONLINEIDENTITIES
[20:29] <lifeless> invites sent
[20:39] <rockstar> rick_h, I make a <script type="text/x-template"> with my template code inside, and then do Y.one().getContent() to get the template.
[21:46] <deryck> abentley, r=me for your upgrade branch.
[21:47] <abentley> deryck: thanks.
[21:59] <lifeless> wgrant: bug tag portlet is bugsummary based now right ?
[21:59] <wgrant> lifeless: I think so, but don't quote me on that.
[22:08] <deryck> Later on, everyone.
[22:12] <lifeless> rick_h: btw, I've replied to the MP - but -- pydoc set.discard :)
[22:18] <rick_h> lifeless: what MP is this?
[22:19] <lifeless> rick_h: the ec2 land notification error one
[22:19] <lifeless> maybe it wasn't yours
[22:19] <rick_h> lifeless: ah yea. I didn't see a comment in my email, /me goes to look again
[22:20] <rick_h> oh bah, completely missed that. What I get for trying to rush a quick fix through
[22:23] <lifeless> what you did works, but its not exactly idiomatic :)
[22:23] <rick_h> lifeless: yea, gotcha. Missed discard when I hit the docs on remove() today.
[22:41] <StevenK> wallyworld_, sinzui, wgrant: http://pastebin.ubuntu.com/834556/
[22:43] <sinzui> wgrant, wallyworld_: These are the projects that violate the commercial subscription for commercial features policy http://pastebin.ubuntu.com/834571/
[22:43] <sinzui> I will deal with these tomorrow
[22:47] <wgrant> omg qastaging bug updates so fast
[22:48] <StevenK> Haha
[22:51] <lifeless> wgrant: \o/
[22:56] <cody-somerville> sinzui, how do you intend to deal with them?
[22:57] <sinzui> cody-somerville, Not sure yet. I could land a branch to let me give the projects a commercial subscription, or I get a webops to add the proprietary checkbox to them so that I can apply the subscription with the current rules
[22:58] <cody-somerville> Some of those projects are PES projects.
[23:00] <sinzui> They were not setup correctly. I think all are probably valid uses. I just need to get the power to complete their setup
[23:13] <StevenK> wgrant: http://pastebin.ubuntu.com/834599/