[00:00] <lifeless> any reason we can't run it right after ?
[00:01] <wgrant> It'd run into the 0902 run, so that wouldn't happen.
[00:03] <lifeless> wgrant: can has review?
[00:03] <wgrant> lifeless: Sorry, missed that. Will look in a sec.
[00:03] <wgrant> Just fixing test failures from yesterday's largish branch series.
[00:23] <wgrant> lifeless: Could you do the sort of query that jtv asked for https://code.launchpad.net/~jtv/launchpad/bug-613823/+merge/75773?
[00:23] <wgrant> lifeless: The approver is cronned on staging.
[00:23] <lifeless> wgrant: hmm ?
[00:24] <wgrant> lifeless: There are QA instructions in that MP.
[00:24] <wgrant> I don't have staging DB access.
[00:24] <lifeless> sorry to be a nuisance, but can you translate to sql ?
[00:25] <wgrant> SELECT * FROM translationimportqueueentry WHERE error_output IS NOT NULL AND status = 5 ORDER BY date_status_changed DESC LIMIT 10;
[00:25] <lifeless> 0
[00:26] <wgrant> That's upsetting. I guess I will check it with hloeung later.
[00:29] <wgrant> lifeless: Does oops-timeline really only lose us two lines of code?
[00:30] <lifeless> wgrant: yes, but it saves duplication for other folk glueing them together
[00:30] <wgrant> Two lines of duplication?
[00:31] <lifeless> about 10
[00:31] <wgrant> stsly?
[00:31] <lifeless> duplication has never been about size of code though
[00:31] <wgrant> srsly?
[00:35] <wgrant> lifeless: Do our consumers cope with the s/db_statements/timeline/?
[00:36] <mwhudson> https://code.launchpad.net/~mwhudson/launchpad/feature-flag-xmlrpc/+merge/75673 if anyone is bored...
[01:09] <lifeless> wgrant: oops-tools is a version locked buildout project.
[01:10] <lifeless> wgrant: it uses datedir-repo which this change doesn't affect, because its not a labelled key in the rfc822 format
[01:11] <lifeless> wgrant: that said, I have a branch for it which updates-and-corrects
[01:12] <lifeless> wgrant: that also needs a review :) - code.launchpad.net/~lifeless/oops-tools/timeline/+merge/75941
[01:15] <lifeless> mwhudson: ping
[01:16] <mwhudson> lifeless: hello
[01:17] <lifeless> want to talk (you know, by airwaves) about branch access?
[01:18] <mwhudson> ah sure
[01:18] <mwhudson> lifeless: mumble/skype/pots
[01:18] <mwhudson> ?
[01:18] <lifeless> the second door
[01:18] <poolie> mwhudson, just a random idea
[01:19] <poolie> is it cleaner to pass a dict that can contain a username and possibly other stuff?
[01:19] <poolie> i don't know if that will be easier to evolve or not
[01:19] <mwhudson> poolie: what would the values in the dictionary be?
[01:19] <lifeless> objects!
[01:19] <poolie> username='mbp' client_ip='1.2.3.4'
[01:19] <poolie> etc
[01:19] <mwhudson> ah
[01:19] <poolie> bzr_version='2.4.4'
[01:19] <mwhudson> lifeless: haha, this is xmlrpc
[01:23] <poolie> #quotes
[01:27] <wgrant> lifeless: Ahh, so it doesn't actually make a difference in the serialised format?
[01:34] <lifeless> right
[01:59] <lifeless> wgrant: were you going to review the oops-tools one too ?
[02:01] <wgrant> lifeless: Done.
[02:05] <StevenK> Oh look, pocketlint deals with JS.
[02:05] <StevenK> If only I knew that on Friday.
[02:05] <nigelb> heh
[02:06] <nigelb> What happened on Friday?
[02:06] <nigelb> Also, I thought pocketlint dealing with JS was one of its biggest advantages.
[02:07] <StevenK> I was dealing with the same JS branch, but I had broken the JS badly so Firefox didn't love me and refused to render the page
[02:07] <nigelb> Ouch.
[02:07] <nigelb> Didn't firebug help?
[02:07] <StevenK> No, it just told me I had a syntax error on line 68,000 something
[02:08] <StevenK> Which wasn't very handy
[02:08] <nigelb> Yeah.
[02:08] <nigelb> I like how firebug throws a weird bug when you make a mistake in JSON.
[02:08] <nigelb> I spent about 20 minutes for that, until I discovered jsonlint helps.
[02:09] <nigelb> StevenK: But if you click on the error it should take you to that line, letting you debug it.
[02:09] <nigelb> Not like that's easy either.
[02:09] <StevenK> Anyway, pocketlint has solved my issue.
[02:10] <nigelb> :)
[02:10] <nigelb> I hope noone stabs me for the number of revisions I've made undeployable.
[02:11] <wgrant> You've only made 13 undeployable, which is probably the least I've seen from non-APAC breakage.
[02:11] <wgrant> I get stabby when it gets above 50.
[02:11] <nigelb> non-APAC?
[02:12] <StevenK> APAC is Asia-Pacific
[02:12] <wgrant> US/EU breakage often gets nasty.
[02:12] <nigelb> "technically" I live in APAC
[02:12] <wgrant> Well, yeah.
[02:12] <wgrant> Just!
[02:12] <lifeless> easily
[02:12] <lifeless> asia goes -way- west
[02:12] <wgrant> Shh.
[02:13] <nigelb> Middle east is west of me.
[02:13] <nigelb> So, i'm not "just" Asia :P
[02:14] <lifeless> isn't it to the bosphorus?
[02:14] <nigelb> Yeah
[02:14] <lifeless> beautiful river
[02:15] <nigelb> lifeless: At some point I need to pick your brain further re:js-oopsd
[02:15] <nigelb> But at a later point when I'm not sleep deprived!
[02:18] <wgrant> reprocess-hwdb-submissions is doing well for itself.
[02:18] <wgrant> 90272 None: None
[02:19] <lifeless> nigelb: ok
[02:22] <wallyworld___> lifeless: can you tell me the code that gets invoked when serving loggerhead pages like to http://bazaar.launchpad.net/~johndoe/project/files
[02:22] <wgrant> wallyworld___: You're trying to add the privacy overlay thing?
[02:22] <wallyworld___> yes
[02:22] <wgrant> Run away.
[02:23] <wgrant> We have no loggerhead customisation story these days :/
[02:23]  * wallyworld___ starts running
[02:23] <wgrant> Which means we have to copy the LP-specific template and JS into the loggerhead tree. And have it there polluting everyone's installations.
[02:23] <wgrant> Even though it's only relevant to us.
[02:23] <wgrant> And our theme.
[02:23] <wallyworld> yuck
[02:23] <nigelb> Can't fork it?
[02:24] <wgrant> Forking it is not a good option.
[02:24] <nigelb> Like have a branch with launchpad changes, and keep merging trunk into it.
[02:24] <wgrant> We should have an alternate theme.
[02:24] <wgrant> Well.
[02:24] <wgrant> Really we should use LH as a service.
[02:24] <lifeless> erm
[02:24] <wgrant> And import it into the LP UI.
[02:24] <lifeless> right
[02:24] <mwhudson> if request is a ILaunchpadRequest, what is request.principal?
[02:24] <wgrant> But that may happen in three decades.
[02:24] <lifeless> the ideal thing is to make LH a background service.
[02:24] <wgrant> Until then we need something better.
[02:24] <wgrant> mwhudson: *probably* an IAccount.
[02:24] <lifeless> in the mean time, we a) maintain loggerhead, b) deploy trunk.
[02:24] <wgrant> mwhudson: Or it may have an adapter to IAccount.
[02:25] <nigelb> AH
[02:25] <lifeless> Guest73189: your nick is bust :)
[02:25] <Guest73189> yeah :-(
[02:25] <Guest73189> keeps happening
[02:25] <nigelb> So logggerhead won't actually show files form a private branch?
[02:25] <wgrant> nigelb: It does.
[02:25] <wgrant> nigelb: It just doesn't say that it's private.
[02:25] <nigelb> AHH.
[02:26] <mwhudson> wgrant: ah, it's a ILaunchpadPrincipal
[02:26] <nigelb> Stupid question - Isn't loggerhead already a service?
[02:26] <mwhudson> (well, if it's not unauthenticated)
[02:26] <wgrant> mwhudson: Does that handle stuff like IWeaklyAuthenticatedPrincipal?
[02:27] <wgrant> (which should really be INotActuallyAuthenticatedAtAllPrincipalButSomePeopleApparentlyCannotHandleEmailSigningBecauseTheyLikeToUseGmail, but that's a bit long)
[02:27] <nigelb> heh
[02:28] <mwhudson> wgrant: basically
[02:28] <mwhudson> i have a request
[02:28] <mwhudson> i want a person, or None
[02:28] <nigelb> I remember doing this elsewhere.
[02:28] <lifeless> nigelb: it is but it displays a web UI of its own
[02:29] <lifeless> nigelb: using different templates, middleware, and web stack.
[02:29] <lifeless> nigelb: its not a *backend* service that the LP web app can consume
[02:29] <nigelb> AHH.
[02:29] <lifeless> nigelb: its just a sibling website that happens to be themed the same way
[02:29] <nigelb> That means loggerhead should first expose such a service in trunk and then we need to grab that and use that?
[02:29] <lifeless> it has a bit of such a service
[02:29] <lifeless> it needs more
[02:30] <lifeless> and it needs to be -much- faster
[02:30] <nigelb> Agree on that one.
[02:30] <lifeless> its fast-path is tolerable but its slow path needs to be two orders of magnitude faster
[02:34] <lifeless> interesting  https://www.facebook.com/notes/facebook-engineering/making-facebook-self-healing/10150275248698920
[02:34] <mwhudson> (fwiw, i think IPerson(request.principal, None) is what i want)
[02:38] <StevenK> wallyworld__: Can I force an overlay to the top?
[02:38] <wallyworld__> StevenK: you mean so that it always stays on top?
[02:39] <StevenK> wallyworld__: Give me a tick, preparing screenshots
[02:39] <wallyworld__> ok
[02:41] <StevenK> wallyworld__: http://people.canonical.com/~stevenk/Subscribe-popup.png
[02:41]  * wallyworld__ looks
[02:42] <StevenK> wallyworld__: That's the "before" shot -- it's a private bug and I've clicked the "subscribed to all notifications" link for the popup
[02:42] <wallyworld__> and the confirm overlay appears beneath?
[02:42] <StevenK> wallyworld__: http://people.canonical.com/~stevenk/Subscribe-popunder.png
[02:42] <nigelb> Needs z-index magic :-)
[02:42] <wallyworld__> StevenK: overlays have a zIndex propety
[02:42]  * wgrant invokes mpt.
[02:42] <wallyworld__> StevenK: default is 0
[02:43] <StevenK> Oh no, I've angered wgrant.
[02:43] <wgrant> Nested overlays... this doesn't seem right.
[02:43] <wallyworld__> StevenK: http://yuilibrary.com/yui/docs/overlay/
[02:43] <StevenK> wallyworld__: Higher is on top, or lower is?
[02:44] <wallyworld__> StevenK: ummmm. higher i *think*
[02:45] <nigelb> Higher.
[02:45]  * nigelb helpfully links to http://www.w3schools.com/cssref/playit.asp?filename=playcss_z-index&preval=2
[02:45] <wallyworld__> StevenK: sort of agree with wgrant though. i'd like to see the click in the "remove" link result in the confirmation exapnding out below the link via an animation
[02:45] <wgrant> Right.
[02:45] <wallyworld__> sort of like for the stuff i did for confirming bug assignees
[02:45] <wgrant> The dialog mutate by expanding, or using a second step.
[02:45] <wgrant> s/mutate/should mutate/
[02:46] <StevenK> You two suck, or something.
[02:46] <wgrant> Dialogs are bad the best of times.
[02:46] <wallyworld__> you've been peeking in my window again haven't you
[02:46] <nigelb> Actually, I'll agree with them as well.
[02:46]  * wallyworld__ needs to close the curtains
[02:46] <StevenK> s/two/three/
[02:46] <nigelb> So, StevenK wasted 2 days of JS hacking only to be mpt'd :P
[02:47] <StevenK> Not really
[02:47] <StevenK> Since there are two callsites
[02:47] <wgrant> I always expect a few days of hacking on a new technology to have to be thrown out at least a couple of times.
[02:48] <wgrant> And while feature squads seem to like introducing tech debt and terrible UI, I think we should try to do this at least vaguely properly.
[02:48] <nigelb> what's tech debt? I see that used in tags.
[02:49] <wgrant> Launchpad.
[02:49] <nigelb> Heh.
[02:49] <wgrant> Launchpad is mostly tech debt.
[02:49] <wgrant> http://c2.com/cgi/wiki?TechnicalDebt
[02:50] <lifeless> wgrant: I've seen worse.
[02:50] <wgrant> lifeless: Huh?
[02:50] <wgrant> Where?
[02:50] <wgrant> COBOL doesn't count.
[02:50] <nigelb> Ah.
[02:50] <wallyworld__> wgrant: minestar
[02:50] <lifeless> wgrant: Micropay
[02:50] <wgrant> OK, software that isn't meant to be enterprisey?
[02:50] <lifeless> wgrant: .... unlike LP ?
[02:51] <wallyworld__> wgrant: win32 api :-)
[02:51] <nigelb> Isn't LP the enterprisey codehosting website? ;-)
[02:51] <wgrant> LP isn't meant to be enterprisey, I don't think. It is, but I don't think it was meant to be.
[02:51] <lifeless> wgrant: and yeah, a few things do come to mind that rival LP for 'wants refactoring soooo bad'
[02:51] <nigelb> It may not be meant to be enterprisey, but some of the best features are enterprisey.
[02:51] <nigelb> (lp)
[02:51] <lifeless> wgrant: see rule #1: all software sucks.
[02:52] <wgrant> lifeless: We just have no way to make it not suck.
[02:52] <wgrant> Because nobody wants to reduce tech debt.
[02:52] <nigelb> Delete more code. That's code that's guaranteed to not suck :-)
[02:52] <wgrant> Maintenance squads can't fix it, and feature squads won't.
[02:52] <wgrant> => we are fucked
[02:52] <wgrant> :)
[02:52] <StevenK> Everything will be better when we have no criticals.
[02:52] <StevenK> OH WAIT
[02:52] <wgrant> Hahahahahahahhaa
[02:53] <nigelb> Bwahaha
[02:53] <StevenK> I could not help myself ...
[02:53] <wgrant> Speaking of which,.
[02:53] <nigelb> 390 bugs with tech-debt :/
[02:53] <wgrant> nigelb: And that's mostly just the really bad stuff.
[02:54] <StevenK> Bleh, still 260.
[02:54] <StevenK> We are going *backward*
[02:54] <nigelb> wgrant: Some seem to be not very had.
[02:54] <nigelb> *hard
[02:54] <wgrant> nigelb: Some aren't, no.
[02:54] <wgrant> nigelb: And even the big stuff is not hard.
[02:54] <wgrant> I spent a few hours yesterday and very nearly disposed of Zopeless.
[02:54] <StevenK> wgrant: How did that turn out?
[02:55] <wgrant> StevenK: Some test failures in the last branch in the series.
[02:55] <wgrant> Which removes ZTM's commit/abort/begin methods, and initZopeless' return value.
[02:55] <wgrant> Leaving ZTM to be moved into DBConfig in the next branch.
[02:55] <wgrant> Still have to strip out Zopeless mail somehow.
[02:56] <wgrant> But it's all pretty well detangled now.
[02:56] <lifeless> great
[02:56] <wgrant> initZopeless' callsites are limited to core base classes and buildd-manager.
[02:56] <wgrant> Which means we can finally untangle the damned dbuser handling.
[02:56] <wgrant> Which is roughly quadruplicated at the moment.
[02:57] <mwhudson> poolie: is there a reason that there are scopes team:foo but server.edge?
[02:57] <wgrant> And it also means the Zopeless layers can die, which simplifies things a bit.
[02:57] <mwhudson> i.e. ':' vs '.'
[03:01] <poolie> mwhudson, i don't think there's any really good reason
[03:01] <poolie> you could look at it as 'server_edge=True' vs 'server=edge
[03:03] <lifeless> o/ 90K hwdb exceptions
[03:04] <wgrant> Yup, the reprocessing seems to be going well...
[03:04] <lifeless> 181 AttributeError: 'LaunchpadTimeoutError' object has no attribute '__traceback__' looks suspect
[03:04] <wgrant> lifeless: I pointed that out last week, yeah. The attempted reraising is bad.
[03:04] <wgrant> __traceback__ was added in 2.7, wasn't it?
[03:04] <lifeless> wgrant: did you file a bug ?
[03:04] <wgrant> Maybe even 3.x.
[03:04] <wgrant> No.
[03:04] <lifeless> wgrant: or reopen it ?
[03:04] <wgrant> I had three production breakages.
[03:04] <lifeless> I'm not criticising
[03:05] <lifeless> I'm asking so I don't duplicate work.
[03:05] <wgrant> You should have been :P
[03:05] <wgrant> I haven't, no.
[03:05] <wgrant> Well, really I wanted to see if anyone else would pick it up.
[03:05] <lifeless> IIRC benji worked on it ?
[03:05] <wgrant> I think that's right.
[03:05] <wgrant> lifeless: So, for science, I'd like to leave it a couple of days and see if a maintenance squad notices.
[03:06] <lifeless> well
[03:06] <lifeless> I've mailed benji
[03:07] <wgrant> :(
[03:07] <StevenK> SUCCESS!
[03:07] <StevenK> My confirmationoverlay works for +subscriptions
[03:08] <StevenK> wallyworld__: *prod*
[03:08] <wallyworld__> StevenK: ouch!~
[03:08] <wallyworld__> StevenK: excellent
[03:09] <wallyworld__> StevenK: you are now a yui expert :-)
[03:09] <nigelb> Trapped! :P
[03:09] <wallyworld__> and i'll assign all the js bugs to you!
[03:09] <StevenK> wallyworld__: Suggestions about how to break up the form_content in http://pastebin.ubuntu.com/692723/ ?
[03:09]  * wallyworld__ looks
[03:09] <nigelb> wgrant: Deploying today?
[03:10] <wallyworld__> StevenK: you can use a join
[03:10] <wallyworld__> give me a sec and i'll find an example
[03:10] <wgrant> nigelb: Funny you should ask.
[03:10] <wgrant> 13:09:58 < wgrant> hloeung: We need to do a nodowntime rollout today so we can turn gina on.
[03:10] <wgrant> nigelb: So, you weren't quite perfectly timed, but 'tis acceptable.
[03:10] <nigelb> wgrant: Almost immediately? :-)
[03:11] <nigelb> what channel was that? Canonical IRC?
[03:11] <wgrant> Maybe. Some preparation to do, and we are down to one LOSA this week.
[03:11] <StevenK> nigelb: Yes, a private one.
[03:11] <wgrant> Yeah, that was #launchpad-ops on the Canonical network.
[03:11] <lifeless> mwhudson: don't you hate all the boilerplate glue to say 'this code at that endpoint' ?
[03:11] <mwhudson> lifeless: YES
[03:11] <nigelb> StevenK: ah, I have an example of join somewhere I think.
[03:11] <mwhudson> i used a bit less boilerplate than some though
[03:11] <wallyworld__> StevenK: search for join('') or join("") in js
[03:11] <wallyworld__> there's quite a few places
[03:12] <mwhudson> some endpoints have the xml-rpc methods in a view on the application endpoint object
[03:12] <wallyworld__> StevenK: you can use string concat if it's only 2-3 lines.
[03:12] <mwhudson> i just put the methods on the application endpoint object
[03:12] <nigelb> StevenK: ['foo', 'bar'].join('')
[03:12] <wallyworld__> but any longer, a join is recommended
[03:12] <nigelb> where foo and bar are 50 to 70 chars each.
[03:13] <nigelb> wgrant: I'm technically a jQuery person more, but YUI is quite neat :-)
[03:13] <nigelb> err
[03:13] <nigelb> wallyworld__: ^
[03:14] <wallyworld__> nigelb: ?
[03:14] <nigelb> wallyworld__: I played around a lot with it for that bug title fix. Its different, but now I think in a better way.
[03:16] <wallyworld__> nigelb: oh, you mean you like yui. it's not too bad actually. i think it's 2nd most popular framework behind jQuery
[03:16] <StevenK> wallyworld__, nigelb: Fixed, thanks.
[03:16] <nigelb> StevenK: \m/
[03:17] <StevenK> I think I need to revert bug_subscription_portlet changes while I work out how to expand it
[03:17] <StevenK> Perhaps I'll do the changes in two branches
[03:18] <lifeless> mwhudson: I've done a review
[03:19] <lifeless> mwhudson: its probably a bit opaque. Two key things - please don't duplicate code (team: magic string handling), and a bit fuzzier one that you may want to ping me on
[03:19] <mwhudson> lifeless: you have?  i don't see a review
[03:19] <lifeless> mwhudson: process-incoming.py
[03:19] <mwhudson> ah
[03:19] <mwhudson> lifeless: did you see my response to poolie's comments?
[03:20] <StevenK> wallyworld__: I'll grab you after lunch on how to test this thing?
[03:20] <wallyworld__> StevenK: ok
[03:20] <nigelb> YUI tests! Fun! :-)
[03:20] <StevenK> wallyworld__: No promises on where I'll grab you
[03:20] <lifeless> yes, I think dict for scopes was confusing (because scopes are containers), but coming from the same place I am
[03:20] <StevenK> :-P
[03:20] <wallyworld__> oh, one can only hope
[03:21] <lifeless> mwhudson: docs are in docstrings.
[03:22] <mwhudson> lifeless: were you under the impression that i know what you're talking about?
[03:23] <lifeless> mwhudson: yes!
[03:23] <lifeless> mwhudson: poolie pointed you at docs, you found an empty file.
[03:23] <mwhudson> well, i still don't know what needs to be _updated_
[03:23] <lifeless> mwhudson: I believe they are in module docstrings instead
[03:23] <mwhudson> all the code i added has docstrings
[03:23] <lifeless> yes, but nothing points at your code; thats the point I think.
[03:24] <mwhudson> ah oik
[03:24] <lifeless> __init__.py
[03:27] <mwhudson> lifeless: were you reviewing the originally proposed version, or r13974 ?
[03:27] <lifeless> mwhudson: the mailed out version
[03:27] <mwhudson> lifeless: ok, look again please
[03:29] <lifeless> much better
[03:45] <lifeless> mwhudson: back to you :)
[03:46] <mwhudson> lifeless: lol, guess what my working copy looks like
[03:47] <mwhudson> default_scopes = (DefaultScope(),)
[04:00] <lifeless> mwhudson: :)
[04:02] <mwhudson> lifeless: back to you (hopefully not much more of this)
[04:04] <lifeless> mwhudson: your example is missing a :
[04:04] <lifeless> 'codehosting.use_forking_server', ['user:' + user_name])
[04:04] <lifeless> ->
[04:04] <lifeless> 'codehosting.use_forking_server', ['user:' + user_name]):
[04:05] <mwhudson> ah
[04:05] <mwhudson> ok
[04:07] <mwhudson> lifeless: thanks
[04:08] <mwhudson> i wonder if i can still land code ...
[04:08] <lifeless> should be able to
[04:08] <lifeless> have I put you in the emeritus team yet ?
[04:08] <mwhudson> don't think so
[04:09] <lifeless> want me to?
[04:09] <mwhudson> lifeless: are you aware of a bug report about this?
[04:09] <lifeless> about what?
[04:09] <lifeless> oh
[04:09] <lifeless> uhm
[04:09] <lifeless> there may be one
[04:09] <mwhudson> lifeless: what impact does being the emeritus team have?
[04:09] <mwhudson> ok, i'll search
[04:09] <lifeless> you'll get review mail which we don't [yet] have a good offswitch for
[04:10] <lifeless> you get bugcontrol privs, and push privs to ~canonical-launchpad-branches
[04:10] <lifeless> mwhudson: ah you are in it
[04:10] <mwhudson> oh ok
[04:10] <lifeless> https://launchpad.net/~canonical-launchpad-emeritus
[04:10] <mwhudson> i don't get review mail...
[04:10] <StevenK> No PQM access?
[04:11] <mwhudson> (which i am happy with, before you do anything about that :p)
[04:11] <lifeless> mwhudson: its not fully setup up :)
[04:11] <lifeless> mwhudson: the intent is to get you review privs, which currently implies mail.
[04:11] <lifeless> mwhudson: [sorry]
[04:11] <mwhudson> lifeless: i appear to be able to approve merge proposals
[04:12] <mwhudson> i am still in ~launchpad mind
[04:12] <lifeless> mwhudson: ah, well then :P
[04:12] <lifeless> mwhudson: its moot till you leave that
[04:12] <mwhudson> ok
[04:14] <lifeless> StevenK: yes, if pqm is integrated with LP (which it was till the code decided their old automation design was wrong)
[04:15] <StevenK> lifeless: Right, so the intent is that canonical-launchpad-emeritus members continue to have PQM?
[04:16] <lifeless> StevenK: the intent is that emeritus devs lose nothing if they are still @ canonical, and lose write-to-deployed-branches only, if they are not.
[04:16] <lifeless> e.g. be as close to an open source project as we can with our current constraints
[04:19] <StevenK> wallyworld__: *grab*
[04:19] <StevenK> wallyworld__: Let me just get some tea
[04:19] <wallyworld__> StevenK: oooh. a little hiher
[04:19]  * StevenK goes to scrub his hands with solvol and steel wool
[04:28] <wallyworld__> StevenK: so you got your tea?
[04:29] <StevenK> wallyworld__: Indeed. Ready when you are.
[04:30] <wallyworld__> StevenK: ok, so you want to write a yui test for your confirmation overlay functionality?
[04:30] <StevenK> wallyworld__: Yup. I'm on mumble if that makes it simpler.
[04:30] <wallyworld__> StevenK: ok. i'll just grab my headset. one of the kids has nicked it
[04:31] <StevenK> Hah
[04:42] <wgrant> Ah, finally.
[04:42] <wgrant> ~jans has added their OpenPGP key.
[04:43] <wgrant> They've uploaded 18 packages this morning.
[04:43] <wgrant> Over several hours.
[04:43] <wgrant> Causes lots of process-upload cronspam :(
[04:43] <StevenK> Hah
[04:43] <wgrant> But maybe it will stop now.
[04:50] <nigelb> wgrant: Don't you have filters for that sort of thing?
[04:52] <wgrant> nigelb: That's one of the few user errors that still generates emails.
[04:53] <wgrant> nigelb: I tried to fix it one day, but then found terrible security holes and never visited that code again.
[04:54] <wgrant> Ah, I see that sinzui had a productive anti-tech-debt Sunday as well.
[04:58] <nigelb> :)
[04:58] <StevenK> wgrant: Oh?
[04:58] <wgrant> StevenK: You might recall I was talking about pagetitles last week on the call.
[04:58] <wgrant> StevenK: sinzui deleted much of it.
[04:59] <StevenK> Neat
[05:05] <mwhudson> wgrant: can you talk to sinzui about blueprints next?
[05:05] <wgrant> Heh
[05:05] <StevenK> Haha
[05:05] <nigelb> Just delete the folder?
[05:05] <nigelb> I can do that. :P
[05:05] <StevenK> mwhudson: You want blueprints deleted?
[05:05] <wgrant> Damn, ZTM will probably fall tomorrow. Then I'll need to find another target for my wrath :(
[05:06] <StevenK> wgrant: lib/canonical
[05:06] <wgrant> StevenK: canonical.lp no longer exists in devel... will that do?
[05:06] <nigelb> WHAT
[05:06] <nigelb> !!
[05:07] <wgrant> canonical.lp, not canonical.launchpad :(
[05:07] <nigelb> Ah!
[05:07] <mwhudson> wgrant: actually, talk to him about ILaunchBag
[05:07] <nigelb> I did wonder if I patched something in canonical.launchpad only for you to delete it.
[05:07] <wgrant> mwhudson: I've tried to rip out bits of that myself, but it's not easy :(
[05:08] <wgrant> ZTM was pretty easy, just very involved and tedious.
[05:08] <StevenK> ILaunchBag needs to die
[05:08] <nigelb> Wait ILaunch*Bag*?
[05:08] <nigelb> I first read it as Bug and I was WTF.
[05:08] <wgrant> It's like a global variable, except more subtly hidden.
[05:08] <mwhudson> wgrant: s/getUtility(ILaunchBag).user/IPerson(get_current_browser_request(), None)/ should do a bunch of it
[05:09] <mwhudson> but you might get a million tests to fix
[05:09] <wgrant> mwhudson: Also doesn't catch non-browser users.
[05:09] <wgrant> eg. the email interface uses LaunchBag in places.
[05:09] <wgrant> Because why not.
[05:09] <mwhudson> ah, this relates to that other bug
[05:09] <mwhudson> scripts don't do participations rite
[05:10] <wgrant> Scripts do a lot of things not right.
[05:10] <wgrant> I need to talk to Zope people about zope.app.testing.functional.FunctionalTestSetup, too.
[05:10] <wgrant> Or maybe just replace FunctionalLayer with ZopelessLayer and see what blows up.
[05:10] <mwhudson> https://bugs.launchpad.net/launchpad/+bug/623199
[05:10] <_mup_> Bug #623199: scripts do not establish valid zope partiticipations <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/623199 >
[05:10] <wgrant> Ah
[05:16]  * mwhudson evaporates
[05:17]  * wgrant gets the condensor.
[05:30] <StevenK> wallyworld__: How can I determine what to put in Y.one() for the overlay?
[05:30] <wallyworld__> StevenK: Y.one('#id') where id is the overlay id if you know it
[05:30] <wallyworld__> StevenK: or Y.one('.yui3-overlay-xxxx') where xxx is the class
[05:31] <StevenK> Yes, my question is how to determine the overlay id, since I don't
[05:31] <wallyworld__> StevenK: you can set the id. give me a minute to check
[05:33] <wallyworld__> StevenK: you have a content_box which you create -eg Y.Node.create("<div #id='foo'></div>")
[05:33] <wallyworld__> StevenK: then you can create the overlay, telling it to use this content_box
[05:34] <wallyworld__> see picker_patcher.js around line 54
[05:34] <wallyworld__> this creates an Activator but the concept is the same I think
[05:36] <StevenK>         var co = Y.one('.yui3-overlay-confirmationoverlay');
[05:36] <StevenK>         Y.Assert.isNull(co);
[05:36] <StevenK> wallyworld__: ^
[05:36] <wallyworld__> StevenK: are you saying the asset fails? or passes?
[05:37] <StevenK> I'm not saying either yet, I'm saying that the code I have at the moment.
[05:37] <wallyworld__> or that's what you are proposing
[05:37] <wallyworld__> ?
[05:37] <wallyworld__> ah. that will work if there's only one confirmation overlay
[05:38] <wallyworld__> otherwise you will need to set the content box
[05:38] <wallyworld__> in the initialisation params
[05:38] <wallyworld__> of the overlay
[05:39] <StevenK> If the subscription js is creating two confirmation overlays, that is news to me
[05:40] <wallyworld__> StevenK: i mean on the page. so long as the node used as the root for .one() is correctly set it will work
[05:40] <wallyworld__> ie use can use Y.one() which is for the whole page or
[05:41] <wallyworld__> node.one() which just looks at children of the node
[05:41] <StevenK> No failures
[05:41] <StevenK> Let me break it
[05:53] <StevenK> wallyworld__: So I get failures, but none about my code
[05:53] <wallyworld__> StevenK: what sort of failures?
[05:54] <StevenK> http://pastebin.ubuntu.com/692789/
[05:55]  * wallyworld__ looks
[05:58] <wallyworld__> StevenK: the test invokes test_unsubscribe_with_warning_action which clicks the link and looks at the mocked io values
[05:58] <wallyworld__> StevenK: so with the confirmation dialog there, it doesn't get to do the expected io
[05:58] <StevenK> wallyworld__: Right, so that's fine that it fails -- but test_on_unsubscribe_updates_info doesn't fail
[05:58] <wallyworld__> but since your test is failing, it may be that the Y.one(.xxxx) is wrong
[05:58] <StevenK> My test is failing to fail
[05:58] <wallyworld__> i would use firebug to inspect the css class used
[05:59] <wallyworld__> for the confirmation overlay
[05:59] <StevenK> class="pretty-overlay-window yui3-widget yui3-overlay yui3-pretty-overlay yui3-lazr-formoverlay yui3-lp-app-confirmationoverlay yui3-widget-positioned yui3-widget-stacked"
[05:59] <StevenK> That bit?
[06:00] <wallyworld__> yep, use 'yui3-lp-app-confirmationoverlay'
[06:00] <StevenK> With no dot?
[06:00] <wallyworld__> sorry, with a dot
[06:01] <wallyworld__> StevenK: to be pedantic, you could use Y.one('.yui3-overlay .yui3-lp-app-confirmationoverlay')
[06:01] <wallyworld__> which will require both classes to be present
[06:01] <wallyworld__> but try the simple case first
[06:19] <StevenK> wallyworld__: Which still doesn't fail how I want
[06:20] <wallyworld__> StevenK: how does it fail now?
[06:20] <StevenK> wallyworld__: The same way
[06:20] <StevenK> Which means Y.Assert.isNull(co) is true
[06:21] <wallyworld__> StevenK: and you are sure the overlay is always being created
[06:21] <StevenK> wallyworld__: Well, I'd like to debug this somehow, but I have NFI how
[06:22] <wallyworld__> StevenK: you open the html harness in chrome and use firebug
[06:22] <wallyworld__> or firefox
[06:22] <wallyworld__> but for yui tests, chrome seems to work better
[06:22] <wallyworld__> run the tests one to load the scripts, then switch to the test_xxxx.js script and set a breakpoint
[06:22] <wallyworld__> and hit refresh
[06:29] <poolie> o/ wallyworld__
[06:29] <wallyworld__> hi poolie
[06:33] <wallyworld__> StevenK: i may have mislead you. to test for both classes, you use Y.one('.foo.bar') <- without the space, slip of the fingers
[06:34] <wallyworld__> poolie: how can i help?
[06:36] <poolie> just saying hi
[06:37] <wallyworld__> poolie: just checking, just in case :-)
[07:01] <jtv> hi mrevell!
[07:01] <mrevell> Morning!
[07:02] <jtv> mrevell: we just rolled out a small but hopefully helpful Translations change that may be worth announcing.
[07:02] <jtv> Any suggestions for how/where I ought to do that?  I haven't kept track.
[07:03] <mrevell> jtv, I'd always favour a blog post. We can then reference that elsewhere.
[07:04] <lifeless> wgrant: closing in on u1; up for 2 tiny reviews in the same theme ?
[07:04] <mrevell> Top notch, btw.
[07:04] <jtv> thanks mrevell
[07:05] <rvba> wgrant: Hi, if you haven't (re-)reviewed my branch yet, I'll split the changes like you suggest.
[07:06] <wgrant> rvba: That would be great -- as it stands it's pretty impractical to see what's what, as I'm sure you've found.
[07:06] <wgrant> lifeless: Possibly. Links?
[07:06] <lifeless> https://code.launchpad.net/~lifeless/python-oops-wsgi/timeline/+merge/75960 https://code.launchpad.net/~lifeless/python-timeline/wsgi/+merge/75959
[07:06] <rvba> wgrant: Indeed. I'll do that this morning.
[07:26] <lifeless> wgrant: ^
[07:27] <poolie> wallyworld__, hey thanks for grabbing bug 696954, that has bothered me in the past
[07:27] <_mup_> Bug #696954: Allow persons in project roles to access private bugs <disclosure> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/696954 >
[07:27] <wallyworld__> poolie: np. it's on the disclosure todo list :-)
[07:28] <poolie> hm
[07:29] <poolie> kinda seems like some scope creep there
[07:29] <poolie> but i'm happy it's getting done
[07:29] <poolie> i think there may be dupes or near dupes of it
[07:29] <poolie> no need to find them now i guess
[07:29] <wallyworld__> poolie: disclosure covers who has access to information just as much as who doesn't
[07:30] <wallyworld__> i'll try and see that any dupes are linked to this bug
[07:32] <lifeless> wallyworld__: you'll need to be very careful about query changes - lots of room for foot-gun on performance in this area; OTOH brad snuck some of it in already before the re-org, so we may be lucky.
[07:33] <wallyworld__> lifeless: the accepted pattern seems to be union of sub queries. i've put up a mp this afternoon along those lines and was going to do something similar here
[07:33] <lifeless> wallyworld__: its not so much a matter of patern, as bug queries being right on the cliff face of timeouts
[07:34] <lifeless> wallyworld__: so adding more work to them has a high probability of pushing them over the cliff
[07:34] <poolie> wallyworld__, so it's kind of a beer conversation but it kind of seems like tackling every bug kinda related to the feature may cause features to run long and starvation of other areas
[07:34] <lifeless> wallyworld__: -> need to make it as much faster as the extra work you are asking it to do.
[07:34] <poolie> but i am really happy to see this one fixed
[07:34] <lifeless> wallyworld__: I'd allow several days for dealing with performance impacts alone
[07:35] <poolie> wallyworld__, oh the one i filed was bug 746887
[07:35] <_mup_> Bug #746887: private bugs get stuck invisible to developers <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/746887 >
[07:35] <poolie> which is a direct dupe of yours, i'd say
[07:35] <poolie> but now duped against bug 696973
[07:35] <_mup_> Bug #696973: There are no roles that can see all private artifacts in (public or private) projects <disclosure> <projects> <teams> <users> <Launchpad itself:Triaged> < https://launchpad.net/bugs/696973 >
[07:36] <wallyworld__> lifeless: recently, bug task assignee was added to the allowed viewers of private bugs. i've taken the same approach for https://code.launchpad.net/~wallyworld/launchpad/pillar-owners-private-bug-visibility-702429/+merge/75961 i can give you some sql to run on staging if you want
[07:37] <wallyworld__> poolie: i'll see if yours is a dup and link it
[07:37] <lifeless> wallyworld__: its not that simple :) - you'll find you need to look at prod (because its in the grey area), and compare bug search timeout counts before/after you go live, and see if there is a regression, and if so toggle it off.
[07:38] <wallyworld__> lifeless: actually, i can optimise it a bit - only do the sql depending on which pillar is not none
[07:39] <wallyworld__> lifeless: ok. i'll make the optimisation before i land. and gather some stats as you suggest
[07:39] <lifeless> wallyworld__: how? (We have queries that cover all pillars - site wide bug queries)
[07:39] <lifeless> wallyworld__: one big thing you can do to make this safer is feature-flag the new query.
[07:39] <lifeless> easy to do, big rewards, I mean.
[07:40] <wallyworld__> lifeless: yes ok. optimisation not feasible as you say. but i will do a ff
[07:41] <wallyworld__> actually, i could do the project roles work as per 969793 behind the same ff perhaps
[07:41] <lifeless> bug 969793
[07:42] <lifeless> no mup?
[07:42] <wallyworld__> um, 696954
[07:42] <wallyworld__> sorry
[07:42] <wallyworld__> wrong bug
[07:42] <lifeless> bug 696954
[07:42] <_mup_> Bug #696954: Allow persons in project roles to access private bugs <disclosure> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/696954 >
[07:49] <lifeless> wallyworld__: cool; if you need specific stuff tested, yes I'd be happy to help.
[07:50] <lifeless> wallyworld__: we can only get pretty gross results from staging as I mentioned though :( - clearly good and clearly bad, but its poor on 'maybe'
[07:50] <wallyworld__> lifeless: thanks. i guess i'll need you if it all blows up on prod and we have to turn off the ff :-)
[07:51] <lifeless> wallyworld__: trivial queries will always be fine. You'll have trouble, if you do, on: project queries (e.g. launchpad-project), and Ubuntu queries, and site-wide queries.
[07:53] <wallyworld__> lifeless: well fingers crossed. if you are interested, https://pastebin.canonical.com/52955/ the unions after bug task assignee are the new ones
[08:04] <adeuring> good morning
[08:09] <rvba> wgrant: I know you're busy right now and this is not urgent at all, but I've refactored the branch: the first one is https://code.launchpad.net/~rvb/launchpad/sync-bug-827608-credit-copy/+merge/74769 and the second one is https://code.launchpad.net/~rvb/launchpad/sync-bug-827608-credit-copy-2/+merge/74958
[08:25] <bigjools> lifeless: are you around in about 20 minutes to talk about python-oops?
[08:25] <lifeless> I think so
[08:26] <bigjools> thanks, just need to do my team call
[08:30] <lifeless> wgrant: sorry to be a nag, was that yes or no to the reviews?
[08:30] <wgrant> lifeless: Sorry, unexpectedly busy. I can look tomorrow (I'm OCR), but I guess you want to toss them at someone else.
[08:31] <lifeless> I'm nearly EOD too, I may just nab you in the morn
[08:31] <lifeless> I need to finish the storm component before it all becomes relevant.
[08:31] <lifeless> thats nearly done
[08:46] <bigjools> lifeless: hi
[08:46] <bigjools> skype?
[08:47] <lifeless> sure
[08:49] <cjwatson> ok, what the heck does https://launchpad.net/ubuntu/+source/clang/2.9-11ubuntu1/+build/2792745 mean
[08:49] <cjwatson> "Currently building" "Finished 7 hours ago (took 18 hours, 12 minutes, 50.6 seconds)"
[08:50] <cjwatson> definitely still going, still getting build output
[08:50] <bigjools> it's a bug
[08:50] <thumper> cjwatson: confused
[08:50] <thumper> hi bigjools
[08:50]  * bigjools looks up the bug
[08:50] <bigjools> yo thumper
[08:50] <wgrant> cjwatson: Yeah, came upon that earlier... it finished on celbalrai, but then $something happened and it was redispatched. I haven't seen that happen for 18 months...
[08:51] <wgrant> cjwatson: It is building now, and should upload as normal in ~22 hours, at which time it will look sensible again,.
[08:51] <bigjools> I think it's part of bug 717969
[08:51] <_mup_> Bug #717969: storeBuildInfo is sometimes ineffective <boobytrap> <buildd-manager> <Launchpad itself:Triaged> < https://launchpad.net/bugs/717969 >
[08:51] <cjwatson> ah, ok, I wouldn't have been able to find that bug :)
[08:51] <wgrant> That's a possibility, yes.
[08:51] <wgrant> It's not a case of that bug that we've seen before, but it is a similar sort of thing.
[08:51] <bigjools> the bug title needs to change
[08:52] <bigjools> might it have been to do with the FDT?
[08:52] <wgrant> bigjools: No, this was hours ago.
[08:52] <wgrant> The initial issue was 6 or 7 hours ago.
[08:52] <cjwatson> should I add a screenshot or something to that bug?  The evidence will go away in the near future
[08:52] <bigjools> ok
[08:53] <wgrant> cjwatson: That would probably be useful. Also useful is the API representation of the build: add /api/devel to the start of the path to get that.
[08:53] <cjwatson> OK
[08:53] <bigjools> lifeless: ok ready when you are, can't see you on skype
[08:55] <lifeless> I'm rbtcollins
[08:56]  * bigjools blind dials
[09:58] <danilos> lifeless, hi, where's the code for ppr pages? I assume it process launchpad appserver log files, right?
[09:58] <danilos> s/process/processes/
[10:02] <mpt> StevenK, whatever it was I did, I apologize
[10:03] <lifeless> danilos: ztrace files yes
[10:03] <lifeless> danilos: its in the lp tree
[10:05] <danilos> lifeless, oh right, thanks
[10:07] <danilos> lifeless, btw, how would you feel if we add the request duration to the apache log files as well?
[10:08] <lifeless> danilos: no particular opinion; I thought apache log format had that anyeway
[10:09] <danilos> lifeless, it doesn't, unfortunately, common format only lists request *end* time afaict
[10:09] <danilos> lifeless, ok, I'll bring it up with LOSAs since this may affect our log processing scripts as well
[10:11] <danilos> and actually it's the time request was received, some stale reference for my previous claim :)
[10:18] <mpt> StevenK, fwiw, I can't see what's in the "Unsubscribe" overlay on that screenshot, but it looks reasonably probable that fixing bug 795180 would make it unnecessary.
[10:30] <StevenK> mpt: I'm fixing a seperate bug -- if a user is unsubscribing themselves from a private bug, they should be warned.
[10:32] <mpt> StevenK, oh, then I'll have to agree with wgrant then. :-) That warning could be indented under the one of those three commands that deprives you of access.
[10:33] <StevenK> mpt: I've already been convinced. I just need more JS knowledge.
[10:34] <mpt> k
[10:51] <wgrant> Ah, good, so I invoked mpt correctly, and shall not incur too much of his wrath.
[11:49] <jtv> stub: I wonder if garbo should report how many iterations and “items” a job got through before being killed.  Nice to know if we're making progress, and whether a job is still needed.
[11:50] <stub> jtv: Sounds useful. Would need to be in DBLoopTuner but that is fine.
[11:51] <jtv> Yeah.
[11:51] <wgrant> stub: Can we abolish database/schema/pending?
[11:53] <matsubara> danilos, hey there, the script that loads oops into the oops-tools database caught up during the weekend and those SMS oopses should now be available for viewing
[11:55] <stub> wgrant: Replacing it with what?
[11:57] <wgrant> stub: Well, it seems to have been used roughly twice in the last two years.
[11:57] <stub> wgrant: I guess it can go - nothing in there at the moment that is useful
[11:57] <wgrant> It should at least be emptied out.
[11:58] <wgrant> Nothing in there is useful now, and I don't really think there's much of a case to put stuff in there.
[11:58] <stub> wgrant: yer. Will need to find somewhere for templates etc. for data migration type scripts. That is going to happen more and more with fastdowntime.
[11:58] <wgrant> That's true.
[11:58] <lifeless> jamesh: https://code.launchpad.net/~lifeless/storm/wsgi closes the loop
[11:58] <wgrant> Nothing in there deserves to stay, but I'm not sure if the directory itself should...
[12:01] <danilos> matsubara, cool, thanks
[12:02] <matsubara> danilos, you're welcome
[12:21] <wgrant> rvba: I think those two branches look fine.
[12:21] <wgrant> rvba: It's hard to say for sure, but the test changes look pretty sane.
[12:21] <rvba> wgrant: Okay.  Thanks for looking at it again.
[12:40] <wgrant> stub: Do you recall why our store names include the config section name? We never change it outside tests...
[12:42] <wgrant> I guess it may have been a WHUI attempt to permit usage of multiple concurrent configs.
[12:43]  * wgrant deletes it to see what breaks.
[12:44] <wgrant> Ah, of course. It's the only way to get the section name into LaunchpadDatabase.
[12:44] <wgrant> Unless I just fix it to always use canonical.config.dbconfig...
[12:44] <wgrant> Which it already does, because the other case is WHUI.
[12:51] <jtv> hey benji—I've got a gigantic lint branch up for review.  Not expecting anyone to read it in full, but since I don't see how it could be Q/A'ed, I'd prefer not to make it self-reviewed as well.
[12:51] <benji> jtv: sure, I'll take a look
[12:51] <jtv> thanks
[12:53] <wgrant> cjwatson: There are some complexities to exporting changeOverride, sadly.
[12:53] <wgrant> cjwatson: Permissions are one difficult bit.
[12:53] <wgrant> Another is getting the same source+binaries behaviour.
[12:58] <cjwatson> I looked at permissions and that part looked OK; launchpad.Edit permissions on SPPH/BPPH already look sane
[12:58] <cjwatson> i.e. basically archive owner with a few warts
[12:58] <stub> wgrant: I suspect the code you are looking at was assembled (I won't say 'designed') before canonical.config.dbconfig existed.
[12:59] <adeuring> bigjools, wgrant: I want to create a set of BinaryPackageBuilds for all possible values of BuildStatus. When I then create a +builds view, the resultset of the view is sometimes empty: http://paste.ubuntu.com/693006/ I get empty results set for the statuses built, building, pending. Any suggestions?
[12:59] <cjwatson> wgrant: and surely the source+binaries behaviour could be handled by the caller?
[12:59] <cjwatson> I would've thought lib/lp/soyuz/scripts/changeoverride.py could basically be transmogrified into an API script
[12:59] <wgrant> cjwatson: Probably, yes, assuming the relevant methods on SPPH are exposed.
[13:00] <wgrant> SPPH.getPublishedBinaries or whatever it is.
[13:00] <wgrant> cjwatson: The API's SPPH.requestDeletion does source+binary implicitly, but that makes less sense for overrides, as they may differ.
[13:01] <cjwatson> requestDeletion's implicit behavior is annoying; it's too constrained to implement lp-remove-package.py over the API
[13:01] <cjwatson> we need to do things like deleting individual NBS binaries, deleting only a source package when its binaries have been taken over by another package, ...
[13:01] <wgrant> stub: Possibly. Since nothing seems to use LaunchpadDatabase or a DBPolicy with anything other than the current section, I'm hoping this ec2 run will succeed. Then I can move ZTM's remaining user handling crap into DBConfig, and it can finally die.
[13:02] <wgrant> cjwatson: Indeed.
[13:02] <wgrant> cjwatson: I forget if we expose BPPH.requestDeletion.
[13:02] <cjwatson> and yes, only being able to overrides for everything in a source package at once would be so limiting as to be useless
[13:02] <wgrant> cjwatson: But do you ever want to delete a source without deleting binaries from that source?
[13:02] <cjwatson> *do overrides
[13:03] <cjwatson> wgrant: only if those binaries have been taken over by some other source.  I'm never sure whether LP will notice that correctly on removal
[13:03] <benji> did the +activereviews page change?  The organization looks different -- and less useful :(
[13:03] <cjwatson> lp-remove-package normally does seem to, admittedly
[13:03] <wgrant> cjwatson: We identify BPPHs for BPRs that were built from a build for the SPR that's being deleted.
[13:03] <cjwatson> the other use case for deleting binaries is when they fail to build (even if they aren't actually NBS) and we don't want to ship unsupportable stuff
[13:03] <wgrant> cjwatson: Names aren't used at all.
[13:04] <cjwatson> OK, that would be safe
[13:04] <wgrant> Yeah, deleting binaries I can understand, and is easily supportable.
[13:04] <wgrant> Deleting sources without their binaries would require slightly more creative API construction.
[13:04] <cjwatson> I can see why you might not want to expose API methods that produce orphaned BPRs
[13:04] <wgrant> Exactly.
[13:05] <benji> oh! it's because it doesn't know who I am, I need to log in
[13:06] <jtv> benji: those are two independent statements, there should be no comma, between, them, how are you, I am fine?
[13:07] <benji> jtv: this is true; my IRC copy editor is on vacation today so you'll have to deal with small imperfections
[13:07] <deryck> Morning, all.
[13:08] <jtv> benji: I see.  Now compare your case to deryck's, who seems to be verbless at the moment.
[13:08] <jtv> Hi deryck.  :)
[13:08] <deryck> hi
[13:08] <benji> jtv: I guess he accidentally a word.
[13:08] <deryck> Not sure I get the verbless comment. ;)
[13:10] <jtv> deryck: I was being a pedantic prick with benji, and when he made up a semi-plausible excuse, I started using you as a bad example instead.  :)
[13:10] <jtv> The “verbless” refers to the absence of verbs in “morning, all.”
[13:11] <deryck> ah
[13:11] <cjwatson> Ah, that invented Victorian grammar. :-)
[13:12] <deryck> Arguments about language on the Internet always end well. ;)
[13:13] <cjwatson> I'll just cite http://languagelog.ldc.upenn.edu/nll/?p=3338 and leave it at that :-)
[13:15] <deryck> heh
[13:30] <deryck> abentley, hi.  we're back to mumble this week.
[13:37] <jml> cjwatson: I stopped reading Language Log ages ago when it went through a period of being a blog about how badly the BBC do science reporting. I'd forgotten how good it can be.
[14:51] <jcsackett> sinzui: available to mumble?
[14:51] <sinzui> yes.
[14:52] <jcsackett> excellent.
[15:10] <abentley> deryck: chat?
[15:10] <deryck> abentley, sure.  let me grab coffee and then meet you in mumble.
[15:10] <abentley> deryck: cool.
[15:17] <lifeless> sinzui: morning.
[15:17] <sinzui> hi lifeless
[15:18] <lifeless> sinzui: did you see the rollback of subscription-changes-on-toggling-private-flag-in-bugs ?
[15:18] <sinzui> I did.
[15:18] <lifeless> sinzui: there is some confusion about whether a) wallyworld was confused or b) I was confused about the design
[15:19] <sinzui> I told wallyworld that OEM has direct subscriptions removed so I thought he did the right thing
[15:19] <lifeless> sinzui: I promised him I would touch base with you directly to clear things up
[15:19] <lifeless> sinzui: do you mean they do the following with the old code: a) make private; b) remove the resulting direct subscriptions ?
[15:19] <sinzui> We can cut that feature and land the structural subscription part only. OEM can report a bug if they believe the behaviour is still broken
[15:20] <sinzui> lifeless, OEM removes anyone they do not know to be associated with their projects
[15:20] <sinzui> It has nothing to do with direct/indirect. It is simply a matter of disclosing info
[15:21] <lifeless> sure, but the indirect-become-direct behaviour is a part of the story
[15:21] <lifeless> in that it requires an explicit act to become a subscriber without that
[15:21] <lifeless> [for a non-project-person]
[15:23] <lifeless> sinzui: anyhow, the result of ditching -all- direct subscribers is that we can't have symmetrical code as we designed : we would have to special case according to increasing or decreasing sensitivity
[15:23] <sinzui> Sure, but disclosing private/secure information costs millions, and users who cannot see who is subscribed (api/email) are trusting Lp to do the right thing
[15:24] <lifeless> agreed on the result of a mistake, but we're talking about the case of taking a bug that was open, private, which clearly means that the info in it was public at one point.
[15:25] <lifeless> such super sensitive things should be created private to start with, so there is no chance of disclosure, and the transition code becomes irrelevant
[15:25] <sinzui> But the subsequent private conversation was never public
[15:25] <sinzui> This case might better be solved by bug linking
[15:25] <lifeless> the transition code flow we discussed was designed for dealing with private-security becomes private-non-security, and vice verca.
[15:26] <lifeless> yes, I think a private discussion about a bug reported by a person outside the project should be done with a lnked private bug
[15:27] <lifeless> is there an option to say 'bugs on this project cannot be filed open' ?
[15:27] <sinzui> As I wrote to wallyworld, we will only deal with structural subscriptions (remove the direct changes) so that the common case works as users expect (and Lp claims to do)
[15:27] <lifeless> ok
[15:28] <lifeless> I think I know what that means, and will look over someones shoulder when v2 of it goes up :)
[15:28] <lifeless> to make sure I understand, so I have a clue and don't trigger a late rollback :)
[15:29] <sinzui> lifeless,  was also cut the unsubscribe-security-contact-bug-supervisor rule when a bug because public/non-security because there was disagreement. I just want to land what we agree solves most of the problem
[15:30] <lifeless> sinzui: oh, thats surprising.
[15:30] <lifeless> sinzui: I agree on landing the uncontentious bits
[15:30] <lifeless> sinzui: but am also curious what the disagreement was
[15:31] <sinzui> wgrant believed the security contact may want to follow the conversation after the issue was made non-security, or even choose to re-secure it if it is decided the change was a mistake
[15:31] <lifeless> btw, I have a sneaking suspicion we might be able to address some performance issues if we materialize subscriptions (like we do teamparticipation). IMBVW
[15:32] <sinzui> wgrant, is planing for that :)
[15:32] <lifeless> sinzui: (re-securing - a test that they receive the 'it is now public' notification would cover that (and be a solid expectation too))
[15:32] <lifeless> sinzui: following-the-conversation : tough. :)
[15:33] <lifeless> sinzui: they can subscribe when they get the notification that says 'xyz is now public and you are no longer subscribed'
[15:33] <bigjools> lifeless: 1. wth are you still doing awake, and 2. any objections to me throwing the management rabbit  plugins in the LP PPA?
[15:33] <sinzui> lifeless,  yes, ensuring notification may be the correct way to handle this.
[15:33] <lifeless> bigjools: 1. Cynthia. 2. No objections.
[15:33] <bigjools> copy!
[15:35] <lifeless> bigjools: btw, I think one of the bugs confused you
[15:35] <bigjools> quite possibly
[15:35] <bigjools> write better descriptions then :)
[15:35] <lifeless> bigjools: the ..139 bug is about snarfing issues from *rabbit*, not longpoll
[15:35] <lifeless> the ...136 bug is about issues from longpoll.
[15:36] <bigjools> I realised that much
[15:36] <lifeless> so how is 136 a pre-req for 139 ?
[15:36] <bigjools> did I get them the wrong way around?
[15:36] <lifeless> they are unrelated
[15:36] <bigjools> hmm
[15:37] <lifeless> two separate services, both need tell-us-what-went-wrong integration of some sort, to avoid a human going and looking at log files.
[15:38] <bigjools> yer right, I'm confused. My bad.
[15:38] <lifeless> no worries :)
[15:38] <bigjools> the management interface is quite neat BTW
[15:38] <lifeless> cool
[15:38] <bigjools> I am poking messages through and the web page updates almost instantaneously :)
[15:53] <lifeless> james_w: https://launchpad.net/testr_recipe is a 404
[15:53] <lifeless> james_w: the url is on your pypi page
[15:57] <bigjools> looks interesting that
[15:59] <james_w> well where did that go then?
[15:59] <james_w> I wonder if I ever actually registered it
[15:59] <james_w> ah https://launchpad.net/testr-recipe
[16:13] <stub> lifeless: https://code.launchpad.net/~wallyworld/launchpad/branch-privacy-trigger/+merge/75189 might interest, as it is a DB patch that should land with code changes (the tests for the trigger behaviour)
[16:48] <gmb> jtv: Could you take a look at https://answers.launchpad.net/launchpad/+question/171451 for me? I don't know the answer.
[16:48] <gmb> this one, also: https://answers.launchpad.net/launchpad/+question/171450
[16:49] <bigjools> where do I set the default reviewer for a project?
[16:49] <bigjools> well, trunk branch
[16:50] <bigjools> nm found it eventually
[17:36] <sinzui> jcsackett, do you have a moment to discuss http://pastebin.ubuntu.com/693202/ on mumble?
[17:37] <jcsackett> sure.
[17:58] <timrc> off hand is there an easy way to get get a bug object via a .getBugByURL()-like API call :)?
[18:07] <sinzui> timrc, the lp object has a top-level bug collection. You only need the id from the URL
[18:08] <sinzui> lp.bugs[284141] will get bug #284141 regardless without need of knowing the projects it affects
[18:08] <_mup_> Bug #284141: PPA upload permissions should be decoupled from its team membership. <lp-soyuz> <ppa> <soyuz-upload> <Launchpad itself:Triaged> < https://launchpad.net/bugs/284141 >
[18:08] <timrc> sinzui, okay that can work
[18:08] <timrc> sinzui, thanks
[18:37] <nigelb> jtv: Hey, do you know why your MP (the one linked on your blog post) turns up with an empty diff?
[18:37] <nigelb> s/your/Launchpad
[18:37] <nigelb> That's probably going to be confusing for everyone who clicks through :)
[18:55] <nigelb> sinzui: Heh, after much fun with regressions, I finally fixed the bug title feature :-)
[18:55] <nigelb> s/fun/fail/g works as well.
[18:57] <sinzui> nigelb, I saw. Thank you for following up
[18:58] <nigelb> sinzui: Embarassing mistakes. But learned YUI testing well now :-)
[18:59] <sinzui> nigelb, You have nothing to be embarrassed about. Now wrongly closing 10,00 bugs in production does cause some embarrassment.
[18:59] <nigelb> ...wow
[19:23] <flacoste> nigelb: yes, now 4 years since that event, but sinzui is still talking about it :-)
[19:23] <sinzui> I was traumatised
[19:25] <sinzui> When I am described as "legendary", I think "what? Who knows me?", then I remember the 10,000 bugs.
[19:35] <nigelb> haha
[19:37] <nigelb> sinzui: I was traumatised with nightmares of wgrant stabbing me for making a bunch of revs undeployable :P
[19:39] <sinzui> nigelb, :)
[19:45] <nigelb> sinzui: I think someone new has more "fame" now with the accidental auto-sync that happened this cycle :P
[19:45] <sinzui> :)
[20:20] <lifeless> flacoste: hi; will be with you soon
[20:21] <flacoste> lifeless: no worries, working on the QBR stuff
[20:29] <lifeless> james_w: ah, should be simple to fix the pypi ref then :)
[20:30] <james_w> lifeless, already done
[20:30] <lifeless> james_w: I wanted to look at the code to see if you setup a run --parallel config
[20:30] <lifeless> james_w: but IIUC you use the .testr.conf in the tree, so thats still manual ?
[20:30] <james_w> it also has code to generate .testr.conf
[20:31] <lifeless> cool!
[20:31] <lifeless> does it setup a parallel conf or the older run-without-knowing style?
[20:40] <james_w> it's old
[20:48] <lifeless> if you have a look at testtools .testr.conf, or even testrepositories itself, you can see the changes quite easily.
[20:48] <lifeless> should I file a bug ?
[21:49] <james_w> lifeless, go ahead
[21:52] <jelmer> 'morning lifeless
[21:53] <nigelb> morning... wait a minute.
[21:53] <nigelb> jelmer: aren't you somewhere in Europe? :)
[21:54] <jelmer> lifeless: you approved one of my bzr-search branches and spoke the ever legendary word "doit", but you own lp:bzr-search; is there any chance you can merge it for me or change ownership to ~bzr/~bzr-search?
[21:54] <lifeless> jelmer: no I don't :)
[21:55] <jelmer> lifeless: :-) thanks
[21:56] <jelmer> nigelb: Yeah :-) I think it's evening for both of us, right?
[21:56] <nigelb> I've passed the point where I can call it evening ;)
[21:57] <nigelb> I still haven't slept so I'll claim evening :P
[21:58] <poolie> sleep well, nigel
[21:58] <poolie> and sleep enough
[21:58] <nigelb> :)
[21:59] <nigelb> Thanks poolie!
[23:22] <lifeless> wgrant: reviews plox
[23:56] <lifeless> wgrant: https://code.launchpad.net/~lifeless/python-oops-wsgi/timeline/+merge/75960 https://code.launchpad.net/~lifeless/python-timeline/wsgi/+merge/75959
[23:58] <wgrant> lifeless: Sorry, on a call right now.
[23:58] <lifeless> kk