[00:03] <sinzui> wgrant: mumble
[00:54] <poolie> thumper: hi
[00:54] <thumper> hi poolie
[00:56] <poolie> thumper: did you find out about kanbans?
[00:56] <thumper> poolie: yeah... although it seemed to have missed out one of the bugs and I don't know why
[00:57] <poolie> (just reading my scrollback from my holiday)
[00:57] <poolie> neither do i :)
[00:57] <poolie> which bug? and what mode of kanban were you using?
[01:04] <LPCIBot> Project windmill-devel build #140: STILL FAILING in 1 hr 18 min: https://lpci.wedontsleep.org/job/windmill-devel/140/
[01:27] <lifeless> cjohnston: I suspect your link - I see none
[02:10] <poolie> o/ lifeless
[02:36] <StevenK> wgrant: I've pushed all of packageupload out of notify()
[02:37] <StevenK> Now to fix the tests
[02:38] <wgrant> StevenK: Great!
[02:38] <lifeless> hi poolie
[02:42] <StevenK> wgrant: I had a thought about binary notification too -- We can call notify_spr_less() if all of spr, bprs and customfiles are None. Or we can just fix model/queue to call notify_spr_less() directly
[02:45] <wgrant> StevenK: Possibly.
[02:45] <wgrant> StevenK: What in the main function still needs the SPR?
[02:46] <StevenK> wgrant: def notify()?
[02:46] <wgrant> Right.
[02:46] <wgrant> It's difficult because the SPR has lots of the data we need.
[02:46] <wgrant> eg. Changed-By and Maintainer.
[02:46] <StevenK> wgrant: _buildUploadedFilesLists, _buildSummary, and _sendNotification
[02:47] <wgrant> Which BPR only has normally because we get it from the changes file...
[02:47] <wgrant> but we can possibly get that from the linked SPR.
[03:40] <jtv> Any reviewers in town?
[03:42] <poolie> hi wgrant, stevenk, jtv
[03:42] <poolie> bac, hi?
[03:42] <jtv> hi poolie
[03:43] <StevenK> poolie: Hai
[03:43] <jtv> and hi StevenK, while we're at it :)
[03:56] <StevenK> NCommander: If you show me a diff or a WIP MP, happy to look it over.
[03:59] <StevenK> wgrant: Right, I have nascentupload-announcements.txt passing -- except for the notify_spr_less() call
[03:59] <StevenK> wgrant: Since notify_spr_less() wants the file-object, so it can get the filename
[04:04] <jtv> I haven't touched JS in a while and need to get back into it.  Can anyone help with some Ajax interaction issues?
[04:04] <jtv> Two questions right off:
[04:05] <jtv> 1. When the client waits for stuff to happen on the server, have we got anything better than dumb regular polling yet?
[04:06] <jtv> 2. What's the current pattern for re-rendering a piece of TAL once stuff happens?
[04:10] <jtv> thumper: I know you're not here, but any spontaneous pearls of wisdom would be most welcome.  :)
[04:14] <jtv> lifeless maybe?
[04:14] <thumper> jtv: for what?
[04:14] <jtv> thumper: see above
[04:14] <jtv> "I haven't touched JS in a while" etc.
[04:14] <thumper> jtv: I don't think so
[04:14] <jtv> booo!
[04:14] <thumper> jtv: I believe there is a plan for long-poll
[04:14] <thumper> but nothing is implemented yet AFAIK
[04:14] <jtv> Ah yes, plans.  Don't we love those.  :)
[04:15] <thumper> :)
[04:26] <wgrant> jtv: All we have is dumb regular polling :(
[04:26] <wgrant> You can ask for an HTML representation from lazr.restful.
[04:26] <wgrant> But in general I think it's better to alter the DOM yourself.
[04:26] <wgrant> What exactly are you wanting to do>
[04:26] <jtv> Re-render DSD entries on +localpackagediffs
[04:26] <jtv> …because syncing completes, for instance.
[04:27] <jtv> I think there could be so much to that (especially as changes progress) that it makes more sense to re-render the TAL than to try and mimick the same logic in JS.
[04:28] <jtv> I suppose I could move more into the view so that more of that logic is still done server-side and transferred as data, but then I fear I may end up with, in essence, a custom representation of the HTML.
[04:40] <jtv> wallyworld_: wasn't "4+1" a Vietcong methodology?  Approach quickly, strike quickly, disengage quickly, retreat quickly; prepare slowly.
[04:42] <wallyworld_> jtv: maybe it was. perhaps the software world copied :-)
[04:43] <jtv> But… but… copying is a _bad_ thing isn't it?
[04:44] <jtv> At least in Chinese-influenced cultures, everything catchy needs at least one number in it.  And there aren't that many catchy numbers.
[04:45] <jtv> "One [x], one [y]."  A thousand points of light.  The Four Precepts.  And so on.
[05:07] <wgrant> wallyworld_: How goes QA for bug #302097?
[05:07] <_mup_> Bug #302097: Trying to access rss feeds of a private bug OOPSes <easy> <feeds> <lp-bugs> <oem-services> <oops> <qa-needstesting> <Launchpad itself:Fix Committed by wallyworld> < https://launchpad.net/bugs/302097 >
[05:08] <StevenK> wgrant: Seems I can't just call notify_spr_less() in do_reject() :-(
[05:08] <wgrant> StevenK: Oh?
[05:09] <StevenK> wgrant: So for nascentupload-announcements.txt at least, there are 2 rejections -- one with full content, and one with an incorrect .changes filename
[05:09] <wallyworld_> wgrant: waiting for staging to be updated
[05:15] <wgrant> StevenK: Could you QA bug #787904?
[05:15] <_mup_> Bug #787904: Copying a package into a derived series fails <derivation> <qa-needstesting> <Launchpad itself:Fix Committed by stevenk> < https://launchpad.net/bugs/787904 >
[05:16] <StevenK> Oh, it is
[05:16] <StevenK> I already know the fix is fine
[05:16] <wgrant> Ah, great. Please mark it as such.
[05:16] <StevenK> wgrant: Done
[05:16] <wgrant> Thanks.
[05:17] <StevenK> wgrant: Sorry, I tossed it at ec2 and meant to do so when the qa tagger nagged me
[05:21] <wgrant> wallyworld_: I think I just QA'd it on qastaging.
[05:22] <wgrant> wallyworld_: Needs feeds.qastaging added to /etc/hosts, and has to be accessed over HTTPS, but it works.
[05:22] <StevenK> Are you not sure? :-)
[05:22] <wallyworld_> wgrant: i was told rss feeds don't work on qastaging and that staging is the system to use
[05:22] <StevenK> wgrant: Would an RT to get feeds.qastaging added to DNS be a good step?
[05:23] <wgrant> wallyworld_: It's not in DNS and needs an Apache reconfig to be complete, but feeds.qastaging.launchpad.net is accessible if you poke it hard enough.
[05:23] <wgrant> StevenK: Probably.
[05:23] <wallyworld_> ok :-)
[05:23] <wgrant> "The requested bug is private. Feeds do not serve private bugs."
[05:23] <wgrant> Looks reasonable.
[05:24] <wallyworld_> i think so. better than a yucky error page
[05:24] <StevenK> Hm, ENOLIFELESS
[05:24] <wgrant> netsplit
[05:25] <StevenK> For over ten minutes? Go go Freenode
[05:25] <StevenK>  lib/lp/archiveuploader/tests/nascentupload-announcements.txt
[05:25] <StevenK>   Ran 1 tests with 0 failures and 0 errors in 9.389 seconds.
[05:25] <StevenK> \o/
[05:26] <wgrant> How'd you manage that?
[05:26] <StevenK> By doing evil things
[05:26] <wgrant> That goes without saying.
[05:26] <StevenK> changes['_filename'] = changes_file_object.name
[05:26] <StevenK> ^ That, mostly
[05:26] <wgrant> OK, not that evil.
[05:26] <wgrant> :(
[05:26] <StevenK> The only thing that cares about the filename is notify_spr_less
[05:27] <StevenK> And I can't call it from do_reject, since it has no idea about the callstack
[05:27] <StevenK> Anyway, running -vvm soyuz over it now
[05:27] <wgrant> Great.
[05:27] <wgrant> Then commit, push, and I will examine it and work out what we can do next.
[05:27] <wgrant> To denauseatify it.
[05:28] <StevenK> After the tests or during?
[05:28] <wgrant> After.
[05:33] <wallyworld_> wgrant: hard hard is it to get another field added to a fti and where do i look to see how an existing fti is defined?
[05:33] <wallyworld_> how hard
[05:34] <wgrant> wallyworld_: database/schema/fti.py
[05:35] <wgrant> Reindexing everything is harder.
[05:35] <wgrant> What are you looking to add?
[05:35] <wallyworld_> person . irc nick
[05:35] <wgrant> That's a bit harder.
[05:35] <wgrant> Since that's in a separate table.
[05:35] <wallyworld_> of course. silly me
[05:35] <wgrant> Is the join too expensive?
[05:35] <wgrant> There are not many IRC nicks.
[05:36] <wgrant> emailaddress is the one that needs optimisation, if anything odes.
[05:36] <jtv> Does that need FTI?
[05:36] <jtv> I mean, IRC nicks?
[05:36] <wallyworld_> i'm just thinking out loud
[05:36] <wallyworld_> jtv: no, i said something stuoid without thinking
[05:36] <jtv> no worries then — we all do that
[05:36] <jtv> Who's up for a JS client-server pre-imp call?
[05:37] <NCommander> StevenK: http://paste.ubuntu.com/613055/ (just realized I forgot to put the paste link)
[05:38] <StevenK> NCommander: Indeed you did
[05:40] <StevenK> NCommander: Making a BPR should make builds for you
[05:41] <wallyworld_> jtv: what are you looking to do?
[05:42] <jtv> wallyworld_: just otp back in a sec
[05:42] <wallyworld_> ack
[05:43] <StevenK> NCommander: It looks good -- your imports are all over the place, so I'd suggest running utilities/format-imports over it. You have some spelling errors, and every comment should be a complete sentence -- you're missing some full stops.
[05:43] <StevenK> NCommander: Eight lines of self.assertEquals is mind-numbling, can I suggest a for loop?
[05:43] <StevenK> wgrant: ^
[05:43] <wgrant> There may be a matcher for that.
[05:43] <StevenK> NCommander: Oh, and you import pdb without using it
[05:44] <wgrant> Or it may be in james_w's unlanded branch.
[05:44] <james_w> yeah, I think that's in more-matchers
[05:45] <james_w> land it! :-)
[05:45] <jtv> wallyworld_: back.
[05:45] <StevenK> NCommander: However, if that test passes and you have the publisher changes finalized, put up an MP!
[05:46] <jtv> Here's what I want to do: you've got a page displaying a bunch of items with somewhat complicated state, and I want live updates for that state.
[05:46] <StevenK> james_w: Link me the MP?
[05:46] <wallyworld_> the page stays open for a while?
[05:47] <jtv> Possibly, yes.
[05:47] <wallyworld_> so you want a long poll which we don't currently do :-(
[05:47] <jtv> Ideally, yes.
[05:47] <jtv> But I have what I hope is a pretty efficient poll with some mitigation measures for the load problem.
[05:48] <wallyworld_> i *think* that the option for now would be to set up a js timer and poll yourself
[05:48] <jtv> Right.
[05:48] <wallyworld_> every so often
[05:48] <StevenK> NCommander: But I'd suggest making the changes I suggest first, since any reviewer is likely to pick up on the exact same points.
[05:48] <james_w> https://code.launchpad.net/~james-w/launchpad/more-matchers/+merge/32057
[05:48] <jtv> wallyworld_: and possibly less often for large numbers of objects.
[05:48] <wallyworld_> and i think yuo has some apis which support that
[05:48] <wallyworld_> yui
[05:48] <lifeless> wallyworld_: wgrant: that feeds fix
[05:49] <lifeless> wallyworld_: wgrant: I bet I can still make it oops
[05:49] <wallyworld_> jtv: you can say "execute this emthod after x seconds"
[05:49] <lifeless> without url hacking
[05:49] <james_w> PublishedStateIs along with the matcher that loops over the input and you'd have a test that would make lifeless proud :-)
[05:49] <jtv> wallyworld_: yes, I've seen that.
[05:49] <wallyworld_> lifeless: fire away
[05:49] <wgrant> lifeless: Probably.
[05:49] <wgrant> I don't care about whether the fix is good.
[05:49] <wgrant> I care about whether it breaks stuff.
[05:49] <lifeless> wallyworld_: open two tabs on a public bug. In one make it private. In the other follow the rss link.
[05:49] <wallyworld_> jtv: i think you'd just requeue the method after each invocation
[05:50] <wgrant> lifeless: You failed.
[05:50] <lifeless> wgrant: yes, its deployable.
[05:50] <wgrant> lifeless: It redirects.
[05:50] <wallyworld_> lifeless: i accounted for that case :-P
[05:50] <jtv> wallyworld_: yes—that avoids piling up overlapping poll attempts.
[05:50] <lifeless> wallyworld_: excellent
[05:50] <StevenK> james_w: I suspect that branch needs devel merged in
[05:50] <wallyworld_> lifeless: you don't need two pages. just do an inline js edit of prvacy
[05:50] <lifeless> wallyworld_: I only remembered the work around the link rel=...
[05:51] <lifeless> so, cool.
[05:51] <jtv> wallyworld_: I was thinking: render each item on the page with a "status cookie" that encodes everything about the item that might change and require it to be re-rendered.  To poll, the client sends its item ids with their cookies; the server responds with HTML and fresh cookies for any items that have changed.
[05:51] <wallyworld_> lifeless: thanks for asking though. best to be thorough
[05:51] <jtv> wallyworld_: The cookie would be computed in one place only, so nobody else needs to care what goes into it.
[05:52] <lifeless> wallyworld_: indeed!
[05:52] <wallyworld_> jtv: sounds like a good solution. could you use an etag like lazr restful?
[05:52] <wallyworld_> jtv: that essentially is the same problem
[05:52] <lifeless> sounds heinous http://www.theregister.co.uk/2011/05/25/intel_hybrid_cloud_appup_service/
[05:52] <jtv> wallyworld_: I had no idea lazr.restful did etags!  Yes, that'd be an ideal place for the cookie to go.
[05:53] <wallyworld_> jtv: i *think* lazr restful has js for computing the hash/cookie you could perhaps look to reuse too
[05:53] <StevenK> james_w: No fair having 5 dependant branches deep
[05:54] <lifeless> wallyworld_: jtv: etag can only talk about one object at a time
[05:54] <lifeless> which drives lots of round trips
[05:54] <jtv> wallyworld_: wouldn't that by nature have to be based on the HTML?
[05:54] <lifeless> whats the problem with just doing the UI in js ?
[05:54] <lifeless> if the user doesn't have js, they won't get updates anyway
[05:54] <jtv> But they want to see the same items.
[05:54] <wallyworld_> lifeless: i didn't realise that etag limitation
[05:55] <lifeless> wallyworld_: etags apply to an entity from a url
[05:55] <jtv> And I stupidly thought wallyworld_ was saying lazr.restful had it deeper down where you could do it per item.  :)
[05:56] <jtv> So scratch etags.
[05:56] <lifeless> jtv: the recipes UI does updates using the html representation
[05:56] <wallyworld_> jtv: lifeless: i wasn't sure about how it was implemented. just pointing out it had them in some form in case they were useful for this, but not so
[05:56] <wallyworld_> sorry :-)
[05:56]  * lifeless doesn't understand the problem yet
[05:57] <wallyworld_> lifeless: jtv wants a long poll type scenario to asynchronously update a page i think
[05:57] <jtv> Yes, items on a page.
[05:57] <lifeless> oh, I get that bit
[05:57] <lifeless> I don't understand why the existing answers don't work here
[05:57] <jtv> I asked earlier about existing answers.
[05:58] <wallyworld_> we don't currently have anything like that atm in lp do we?
[05:58] <lifeless> we do page updates in js all the time
[05:58] <StevenK> wgrant: http://pastebin.ubuntu.com/613059/
[05:58] <lifeless> pickers, subscriptions, recipes, bugs
[05:58] <wallyworld_> lifeless: yes, but that;s in response to a user action
[05:58] <lifeless> wallyworld_: so?
[05:58] <wallyworld_> not a server side event
[05:59] <wallyworld_> this is a different scenario afaiu
[05:59] <lifeless> wallyworld_: fire a background poll, it notifies when an object is updated, call into the local js
[05:59] <jtv> lifeless: that's not a very helpful description.
[05:59] <wallyworld_> lifeless: yes, that's the solution that is being canvased
[06:00] <StevenK> wgrant: A lot of the failures are due to tests tossing in StringIO for changes_file_object, which doesn't have a .name
[06:00] <wgrant> StevenK: :(
[06:00] <wallyworld_> we are discussing the implementaion options
[06:00] <lifeless> wallyworld_: jtv: what I'm saying is that finding out about the change, and updating the UI in response, are largely separate problems
[06:01] <jtv> Which is why I posed them as separate questions from the start.
[06:01] <jtv> lifeless: You may want to read about 2 hours back, search for your name.
[06:01] <jtv> We're not confused on that point.
[06:01] <lifeless> ok
[06:01] <wallyworld_> sure. we are more discussing the "finding out about the changes" bit i think
[06:01] <StevenK> wgrant: And getattr(changes_file_object, 'name') makes me cry
[06:01] <wallyworld_> i think jtv has what seems like a reasonable solution
[06:02] <jtv> I was sketching out the solution I had in mind, based on the answers I got earlier about existing solutions.
[06:02] <jtv> The answers were: no, we have nothing better than polling yet; and even though we generally prefer to manipulate the DOM directly for object changes, it is possible to request HTML from lazr.restful.
[06:03] <lifeless> jtv: so, I'm confused again
[06:03] <lifeless> you seem to be describing a sort of complex page-state-diff algorithm.
[06:03] <jtv> Not particularly complex, when you get right down to it; just "send me any updates" but with a single roundtrip.
[06:04] <lifeless> Whats the concrete use case here? Is it really 'any part of the page has changed', or is it 'show the status of jobs for this DSD' ?
[06:04] <jtv> It's showing the status of a DSD—which may include the status of the DSD itself, but also different types of jobs that may be in progress for it.
[06:05] <lifeless> some thoughts:
[06:05] <lifeless>  - detecting a change generally involves as much as work as rendering the object again
[06:06] <lifeless>   - the server knows what would be on the page so why would the client supply stuff to check?
[06:06] <jtv> Why does the server know what would be on the page?
[06:07] <lifeless> because the server renders pages
[06:07] <jtv> It knows _when_ it renders the page.  But after that, it blissfully forgets.
[06:08] <lifeless> yes, But it can redetermine that trivially as needed
[06:08] <jtv> Excuse me?
[06:09] <jtv> How can it do that?
[06:09] <lifeless> render the page?
[06:09] <jtv> That's a different page.
[06:10] <jtv> It's got different DSDs on it.
[06:10] <jtv> That's not the page the user is looking at.
[06:10] <wallyworld_> if there are 100 clients connected at different times, how can the server know what's on each and every client? that's not scalable
[06:10] <jtv> Exactly.
[06:11] <lifeless> wallyworld_: so, in the future, ajax subscription does *exactly that*
[06:11] <lifeless> wallyworld_: but thats not today.
[06:12] <lifeless> jtv: why does it have different DSDs ?
[06:12] <wallyworld_> even in that case though, the server would just push out new state for a domain object and it wouldn't know what's already been rendered
[06:12] <jtv> Because it's a filtered view.  DSDs change status.
[06:12] <wallyworld_> it would be up to each client to "do the right thing"
[06:12] <jtv> A DSD gets resolved, it falls off the page.
[06:12] <jtv> A package change may push a new DSD onto the page.
[06:14] <wallyworld_> lifeless: storm doesn't support sql case statements does it?
[06:14] <lifeless> wallyworld_: sure does
[06:14] <wallyworld_> oh cool.
[06:15]  * wallyworld_ looks for it
[06:16] <lifeless> jtv: then perhaps just request that the dsds present get re-rendered ?
[06:16] <NCommander> StevenK: I don't have changes for it yet, I got tied up withspecs so I only finished the test suite today to see if its sane, as I'm unsure if this is the proper solution. I kinda felt it mightbe clearly to maintain publishing for SUPERSEDED items ...
[06:17] <jtv> lifeless: that's going to be very similar, except with unnecessary rendering and a bigger payload.  Where's the gain?
[06:17] <StevenK> NCommander: Hopefully, the test fails, then?
[06:17] <lifeless> jtv: its simpler
[06:18] <lifeless> jtv: you could just return domain objects, but I got the impression you didn't want to do the ui in js
[06:18] <jtv> That's right, I didn't want to do the UI in JS.
[06:18] <lifeless> though domain objects are often *more* expensive to generate than rendering a page.
[06:19] <jtv> I don't think rending all items takes away much complexity: instead of keeping track of {id: cookie} we'd need to keep track of [id], and that's about all I see changing.
[06:19] <NCommander> StevenK: indeed since everything expect the i386 binary should still be PUBLISHED
[06:19] <jtv> *rendering
[06:19] <wallyworld_> lifeless: sorry. i can't see any native support. i know i can inject the required sql into the find(), i was looking for a built in Expr subclass
[06:19] <StevenK> wgrant: The first 14 errors fixed
[06:19] <wgrant> StevenK: That was easy.
[06:20] <StevenK> 15
[06:20] <StevenK> test_realiseUpload_for_delayed_copies is still broken
[06:20] <wgrant> :(
[06:20] <wgrant> What is its complaint?
[06:20] <lifeless> jtv: it means you don't need a cookie, generation of which is usually expensive [in all similar systems I've sen]
[06:20] <StevenK> wgrant: It was expecting an annoucement mail
[06:21] <wgrant> Hmm
[06:21] <StevenK> wgrant: Let me commit and push
[06:21] <lifeless> wallyworld_: hmm, sorry :(. Would you like some pointers on adding a case statement expr ?
[06:21] <StevenK> % bzr di | wc -l
[06:21] <StevenK> 413
[06:21] <StevenK> I am such a bad person
[06:21] <jtv> lifeless: even if generating the cookie is as expensive as rendering an item, big win.
[06:22] <wallyworld_> lifeless: i should be ok to do that. i'm not sure if i need it. just experimenting at the moment
[06:22] <jtv> lifeless: the cookies can be generated in batch.
[06:22] <lifeless> jtv: rendering can be done in a batch too?
[06:22] <jtv> Are you asking or saying?
[06:23] <lifeless> both I guess
[06:24] <jtv> What I'm saying is, I don't see why generating the cookie and in most cases doing no rendering at all and sending basically no data across the wire is going to be anywhere near as expensive as re-rendering all items on the page and sending them to the client.
[06:24] <jtv> Also, I think saw IE running JS once.
[06:24] <lifeless> i/win 21
[06:24] <jtv> There's no longer a monitor attached to that computer, so I don't know how well it does.  But not replacing items on a page that don't need touching may also be a plus.
[06:26] <lifeless> so, I've fixed something like 10+ timeouts related to generating API objects now
[06:26] <jtv> How does that follow?
[06:26] <lifeless> the API definition for an object includes grabbing *all* the adacent objects and calculating their urls
[06:27] <jtv> Good point: another reason to do it the way I had in mind I guess.
[06:28] <lifeless> the reason I suggested rendering is that rendering is *targeted*
[06:28] <jtv> They're going to have to do something with the internet here, so I'll be offline for a bit.
[06:28] <lifeless> k
[06:28] <lifeless> pick this up in a bit
[06:28] <wgrant> Hm.
[06:28] <wgrant> Did someone break PQM?
[06:29] <wgrant> Nobody fixed the conflict, but it has stopped complaining.
[06:29] <wgrant> ah, buildbot failure.
[06:29] <wgrant> "Set changed size during iteration"
[06:29] <wgrant> WYay
[06:32] <wgrant> wallyworld_: Found any remarkable insights from your ranking experiments?
[06:33] <wallyworld_> wgrant: there is a relatively simple change that will improve the ordering of results while not changing the query too much. the query is quite complex so i'm loath to mess with it too much. i'm also experimenting a bit with a few other things
[06:35] <wgrant> wallyworld_: You mean actually using the rank instead of throwing it away and ordering by displayname?
[06:35] <StevenK> wgrant: The diff should be updated.
[06:35] <wallyworld_> wgrant: yes, in a nutshell
[06:36] <wgrant> wallyworld_: Good luck doing that while not changing the query too much :(
[06:36] <wallyworld_> exact matches to name (lp id) > exact matches to displayname > exact matches to irc nick > partial matches to email
[06:36] <wgrant> What's an exact match to displayname?
[06:37] <wgrant> as in a full string match?
[06:37] <wallyworld_> wgrant: i've got a solution which i expect wiol work but i'm messing with other things before i implement
[06:37] <wallyworld_> yes.
[06:37] <wgrant> wallyworld_: We also need to consider affiliation in ranking, or maybe just filtering... and I'm not sure how trusted affiliation wants to be.
[06:38] <wgrant> Hmm.
[06:38] <wgrant> I'd prefer an FTI rank over a string match.
[06:38] <wgrant> Otherwise you have to get it just right.
[06:38] <wallyworld_> wgrant: we discussed on the call this morning not doing affilliation in rankings first up
[06:38] <lifeless> if you're checking displayname be sure to add a db index for it
[06:38] <wallyworld_> will do
[06:40] <wallyworld_> wgrant: wrt the fti match vs string match. the fti match is still being done too. but if the user does type in an exact match, that should take precedence
[06:40] <lifeless> trust fti to do that
[06:40] <wgrant> wallyworld_: But the FTI rank is not taken into account.
[06:40] <wgrant> Right.
[06:40] <wgrant> If we take FTI rank into account, we'll get full matches and partial matches, in the right order.
[06:40] <wallyworld_> lifeless: the fti will do it but the ranking will be off
[06:41] <wallyworld_> we want exact matches ranked higher
[06:41] <stub> lifeless: "BugTask.sourcepackagename = ss4.sourcepackagename OR ss4.sourcepackagename IS NULL" is better written as "BugTask.sourcepackagename IS NOT DISTINCT FROM ss4.sourcepackagename"
[06:41] <lifeless> stub: doh of course... thanks
[06:41] <wgrant> wallyworld_: FTI rank should do that.
[06:42] <wallyworld_> wgrant: not when fti rank is 0..1 and we use 100 for exact string match on name and 10 for irc nick
[06:42] <wgrant> wallyworld_: Better to tweak those than work around FTI, surely.
[06:43] <wallyworld_> i could look at adjusting the other raqnking values currently in use
[06:43] <wallyworld_> but there must have been a reason for doing it the way it is
[06:43] <wgrant> You've been around Launchpad for long enough to know that's not necessarily true :)
[06:43] <wallyworld_> does our local db on our laptops have fti enabled?
[06:44] <wgrant> Yes.
[06:44] <wallyworld_> cool.
[06:44] <wgrant> launchpad_dogfood=# SELECT Person.name, Person.displayname FROM person ORDER BY rank(fti, ftq('william grant')) DESC LIMIT 10;
[06:44] <wgrant>       name       |         displayname
[06:44] <wgrant> -----------------+------------------------------
[06:44] <wgrant>  me-williamgrant | William Grant
[06:44] <wgrant>  wgrant          | William Grant
[06:44] <wgrant>  me+testing      | William Grant (test account)
[06:44] <wgrant>  shuilongzi      | Basil Bakhtin
[06:44] <wgrant> We just have to balance them with exact name matches.
[06:44] <wgrant> Those results aren't bad.
[06:44] <wgrant> And IRC nick matches.
[06:45] <wallyworld_> wgrant: wrt the exidting ranking. i realise that it may not be "correct" but i do want to try and understand why it was done the way it was in case there's some corner casse or something i'm missing
[06:46] <stub> Those constants were just a guess that have never been tweaked IIRC
[06:46] <stub> Just there to get all exact matches above fti fuzzy matches
[06:46] <wallyworld_> stub: makes sense. wonder why if fti ranks from 0..1 that string matches used 100 though
[06:47] <wallyworld_> if fti gives a ranking of 1 for exact match, then wou;dn't we have used 1 for for explicit exact matches?
[06:48] <stub> wallyworld_: Exact match in a particular field. fti match does stemming, and searches other fields too probably, but will give the same score for 'wgrant' as it would 'wgrants'
[06:48] <stub> And miss you entirely if your name happens to be a stopword.
[06:49] <stub> Try a search for 'Ng' for instance...
[06:49] <stub> fti is setup for english word searches, and names don't really fit that.
[06:51] <wallyworld_> ok. thank for the explanation. sounds like we need to explicitly do any exact string matches we require. and there's none for displayanme yet
[06:51]  * wallyworld_ has to go to soccer training. back later
[06:52] <stub> wallyworld_: We likely need an index created to do exact matches fast and case insensitive. Are exact matches on name useful though? Or do you really want a substring match (slow without further work...)
[06:53] <wallyworld_> stub: i think they are useful. if you know you want to find "Joe Bloggs" you should be able to type that. you may not know his lp nick or email
[06:54] <wallyworld_> i don't think we need substring. fti will cover that? just an index for exact match
[06:54] <wallyworld_> for displayname
[06:55] <wallyworld_> i'm assuming there is already an index for person.name
[06:55]  * wallyworld_ really has to go now
[06:55] <wgrant> stub: Oh yeah, person.fti doesn't have an index on production.
[06:55] <wgrant> stub: We discovered this yesterday.
[07:06] <StevenK> wgrant: New list: http://pastebin.ubuntu.com/613073/
[07:07] <wgrant> StevenK: What's up with soyuz-set-of-uploads?
[07:08] <StevenK> wgrant: distroseriesqueue.txt
[07:08] <StevenK> Sigh
[07:09] <StevenK> wgrant: distroseriesqueue.txt is complaining that spr.name is None for an announcement mail
[07:09] <wgrant> :(
[07:09] <wgrant> spr.name is None, or spr is None?
[07:09] <StevenK> The latter, sorry
[07:09] <wgrant> Right.
[07:09] <wgrant> We probably have to infer it from the BPR or something.
[07:10] <StevenK> So, if spr: name = spr.name, if bprs: bprs....
[07:11] <StevenK> wgrant: The soyuz-set-of-uploads failure is odd: http://pastebin.ubuntu.com/613074/
[07:16] <wgrant> StevenK: Why's it not emailing name16 any more? :(
[07:17] <StevenK> It should be?
[07:17] <wgrant> It was before.
[07:18] <StevenK> wgrant: distroseriesqueue.txt fixed
[07:21] <StevenK> Ah, it's a bug in notify_spr_less
[07:23] <stub> wgrant: whoops
[07:23] <wgrant> StevenK: Your diff is now Full HD.
[07:23]  * stub wonders how that happened
[07:23] <wgrant> stub: Rather...
[07:23] <StevenK> wgrant: Oh?
[07:24] <wgrant> stub: It's all of 50MB when freshly created on DF.
[07:24] <wgrant> StevenK: It is 1080 lines.
[07:24] <wgrant> Getting a little on the large side,...
[07:24] <lifeless> \o/ I feel validated, I fixed a bug this week
[07:24] <stub> fti.py is supposed to maintain all that
[07:24] <StevenK> wgrant: Haha
[07:24] <lifeless> StevenK: yo
[07:24] <lifeless> bah
[07:24] <lifeless> stub: yo
[07:25] <StevenK> Ha
[07:25] <stub> lifeless: yo
[07:25] <lifeless> call?
[07:25] <stub> sure
[07:27] <lifeless> sky.net?
[07:29] <wgrant> 2011-05-26 05:57:06 INFO    2208-62-0 applied just now in 0.3 seconds
[07:29] <wgrant> Success!
[07:32] <poolie> would it be too snarky to edit "Most developers will be happy with [[API/launchpadlib|launchpadlib]],"? :}
[07:32] <lifeless> poolie: ECONTEXT
[07:32] <StevenK> wgrant: 62 is the patch o' doom?
[07:34] <wgrant> Yes.
[07:34] <poolie> the help.l.n/API page
[07:34] <poolie> i was actually going there to add something more objectively useful
[07:35] <poolie> which is the tip about string parameters being encoded as json strings
[07:37] <lifeless> stub: ohhai?
[07:40] <lifeless> zing!
[07:41] <StevenK> lifeless: I think that's your answer ...
[07:41] <StevenK> wgrant: soyuz-set-of-uploads fixed
[07:41] <StevenK> It's still horridly slow
[07:48] <LPCIBot> Project db-devel build #581: FAILURE in 7 min 6 sec: https://lpci.wedontsleep.org/job/db-devel/581/
[07:48] <StevenK> Hmmm
[07:48] <StevenK> bzr: ERROR: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/.bzr/repository/packs/c953fdd6233a6989afbd047b37b58c4b.pack is redirected to https://launchpad.net
[07:48] <StevenK> Again
[07:48] <wgrant> :(
[07:48] <wgrant> StevenK: How'd you fix it?
[07:49] <StevenK> wgrant: soyuz-set-of-uploads? It wasn't even checking the blamer.
[07:49] <wgrant> Ah
[07:49] <wgrant> That might do it.
[07:49] <StevenK> [16:21] < StevenK> Ah, it's a bug in notify_spr_less
[07:49] <wgrant> 191 open critical bugs in launchpad :)
[07:50] <StevenK> Then fix the topic? :-)
[07:50] <wgrant> launchpad-project is still 209 :(
[08:00] <lifeless> stub: https://dev.launchpad.net/ArchitectureGuide/Services
[08:08] <wgrant> StevenK: What's still failing?
[08:10] <StevenK> wgrant: Everything else on that list aside from the two I've mentioned.
[08:12] <jtv> lifeless: we were discussing that DSD page update thingy.
[08:13] <StevenK> wgrant: Are you still looking it over, or do you want to fly to Sydney to kick me in the teeth?
[08:14] <wgrant> StevenK: A hybrid.
[08:16] <StevenK> wgrant: Oh, so you're still looking it over *and* you want to fly to Sydney to kick me?
[08:16] <wgrant> Right.
[08:26] <lifeless> jtv: hi, yes we were.
[08:26] <lifeless> jtv: I have an email I've been trying to get to for a day now, which I want to finish as a priority
[08:26] <jtv> OK
[08:26] <lifeless> jtv: can we raincheck for a little more?
[08:26] <jtv> sure
[08:35] <StevenK> wgrant: distroseriesqueue-dist-upgrader.txt fixed. With a one-line patch. :-/
[08:35] <wgrant> StevenK: Oh?
[08:35] <wgrant> How?
[08:35] <wgrant> I expected it to be harder.
[08:36] <StevenK> wgrant: Adding 'MAINTAINER': '', to the information dict
[08:37] <wgrant> Heh
[08:37] <StevenK> It fixed distroseriesqueue-debian-installer.txt too
[08:37] <wgrant> And translations?
[08:37] <wgrant> Or ddtp or whatever it's called.
[08:38] <StevenK> ddtp-tarball looks like whitespace changes
[08:40] <StevenK> wgrant: ddtp-tarball fixed with http://pastebin.ubuntu.com/613092/
[08:41] <wgrant> Ahh, - is the default version, I guess.
[08:41] <StevenK> Ah
[08:41] <wgrant> You might want to fix that by s/''/'-'/ instead.
[08:41] <StevenK> I can fix that
[08:41] <wgrant> I was going to chastise you for using '' anyway.
[08:42] <StevenK> wgrant: That fixed it, good catch.
[08:43] <wgrant> poolie: Bug #778437 is already released.
[08:43] <_mup_> Bug #778437: Recipe build success sends emails, please stop doing that <email> <qa-ok> <recipe> <Launchpad itself:Fix Released by mbp> < https://launchpad.net/bugs/778437 >
[08:43] <wgrant> poolie: Does it not seem to be?
[08:43] <wgrant> StevenK: Does that change dist-upgrade/debian-installer at all?
[08:46] <wgrant> Is test_realiseUpload_for_delayed_copies still broken?
[08:46] <wgrant> And what about xx-queue-pages.txt?
[08:46] <StevenK> wgrant: Both still pass with the '-' change -- perhaps they don't check the subject.
[08:46] <wgrant> Hm.
[08:46] <wgrant> Would not surprise me :(
[08:46] <StevenK> Haha
[08:47] <StevenK> I believe test_realiseUpload_for_delayed_copies is still broken
[08:47] <StevenK> xx-queue-pages I'm not sure about
[08:48] <StevenK> wgrant: I think that gets us to test_realiseUpload_for_delayed_copies, distroseriesqueue-notify.txt and xx-queue-pages.txt as broken
[08:48] <wgrant> StevenK: Ah, yeah, look at PackageUpload.displayversion.
[08:48] <wgrant> Uses source version, then binary version, then -.
[08:48] <StevenK> Ah yes
[08:49] <StevenK> wgrant: Which of the three do you want me to dig into next?
[08:50] <wgrant> StevenK: Whichever has the least obscure error message.
[08:50] <poolie> wgrant: ooh, that's great
[08:50] <wgrant> Which may well be test_realiseUpload_for_delayed_copies, but possibly not because screw delayed copies.
[08:50] <poolie> i have the mail filtered
[08:50] <wgrant> Ah, heh.
[08:51] <StevenK> wgrant: Haha
[08:51] <wgrant> poolie: But yeah, it was released like 7 hours after it landed.
[08:51] <wgrant> Where by 7 I mean 9.
[08:51] <wgrant> Because I can't count.
[08:52] <StevenK> wgrant: xx-queue-pages: http://pastebin.ubuntu.com/613096/
[08:52] <poolie> i don't have a totally reliable model of which bug state and which branch landing corresponds to 'actually running'
[08:53] <poolie> wgrant: so you qa'd it? thanks
[08:53] <wgrant> poolie: Fix Released means "actually running", unless somebody makes a mistake.
[08:53] <StevenK> wgrant: The bottom one is fixable, once I figure out where that comment is getting injected
[08:53] <wgrant> And it's normally lifeless or I, and we are fairly good at that these days.
[08:53] <StevenK> wgrant: The top one concerns me
[08:53] <poolie> aj
[08:53] <poolie> i mean ok
[08:54] <wgrant> StevenK: The top one is concerning mostly because more tests did not fail.
[08:54] <adeuring> good morning
[08:54] <wgrant> StevenK: It's a reasonable change. But more should have broken.
[08:55] <StevenK> wgrant: Beh, the bottom one is because the older code set "Rejected by archive administrator." as the reason if there was none.
[08:55] <LPCIBot> Project windmill-db-devel build #326: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/326/
[08:55] <wgrant> StevenK: Ah. You should probably do so too.
[08:55] <wgrant> StevenK: Eventually that will be gone, but let's preserve behaviour for now.
[08:56] <wgrant> Also, wow our tests are terrible.
[08:56] <poolie> night all
[08:56] <wgrant> Night poolie.
[08:58] <StevenK> wgrant: Fixed that -- should I correct the subject in the doctest?
[08:59] <wgrant> StevenK: I'm not sure. Why did it change?
[08:59] <wgrant> Did none of the other tests of the ".* rejected" subject change?
[08:59] <wgrant> It seems odd that a single test found it.
[09:00] <StevenK> wgrant: So, rejected messages are interesting -- notify_spr_less() will set the subject as "<changesfile> rejected", but notify() will set it as in calculate_subject()
[09:00] <wgrant> Right.
[09:00] <wgrant> That's what I thought.
[09:00] <wgrant> Sounds reasonable.
[09:00] <wgrant> For now, at least.
[09:00] <wgrant> So change the test.
[09:00] <StevenK> And interestingly, the test is rejecting alsa-utils
[09:01] <StevenK> But the test is coded to expect the subject is 'netapplet-1.0.0.tar.gz rejected'
[09:01] <StevenK> So, fail.
[09:01] <wgrant> Possibly sampledata fail.
[09:01] <wgrant> Wait.
[09:01] <wgrant> *tar.gz* rejected?
[09:01] <wgrant> How does that make sense :(
[09:01] <StevenK> It doesn't!
[09:02] <StevenK> xx-queue-pages.txt fixed
[09:04] <StevenK> wgrant: distroseriesqueue-notify.txt suffers from the same brain damage
[09:04] <wgrant> StevenK: Yay sampledata.
[09:12] <StevenK> wgrant: -notify sorted out, that leaves test_realiseUpload_for_delayed_copies
[09:13] <StevenK> wgrant: Which is strange. It seems to only want an annoucement mail and no other
[09:14] <wgrant> StevenK: That's right.
[09:14] <wgrant> StevenK: Since there is no requester.
[09:14] <StevenK> And I don't want to put a delayed copy hack into notification
[09:14] <wgrant> StevenK: Notifying the signer is probably wrong.
[09:14] <wgrant> Check what the old code did.
[09:14] <wgrant> Are you still using spr.packageupload.signingkey?
[09:15] <StevenK> Yes
[09:15] <wgrant> That's probably it.
[09:15] <StevenK> Er, no
[09:15] <wgrant> :(
[09:15] <wgrant> You're using blamer now?
[09:15] <StevenK> Everything is
[09:15] <wgrant> OK.
[09:15] <wgrant> So whatever is passing in blamer might be wrong.
[09:16] <wgrant> this is just a guess; I may be entirely wrong here.
[09:16] <StevenK> PU.notify() sets it to self.signing_key.owner if signing_key isn't None
[09:16] <wgrant> Hmm. So it should be None for delayed copies still.
[09:16] <StevenK> Let's find out
[09:16] <wgrant> Work out why it's sending the extra email.
[09:16] <wgrant> Then work out why it wasn't sent before.
[09:16] <StevenK> It's a unit test, so I can trace easier
[09:17] <wgrant> doctests rule the world!
[09:17]  * StevenK hangs himself
[09:25] <StevenK> wgrant: (Pdb) p self.signing_key
[09:25] <StevenK> <GPGKey at 0xf332950>
[09:25] <StevenK> :-(
[09:25] <wgrant> StevenK: .. on a delayedcopy?
[09:26] <StevenK> (Pdb) p self.is_delayed_copy
[09:26] <StevenK> True
[09:26] <mrevell> Morning
[09:26] <StevenK> wgrant: So, yes
[09:27] <wgrant> StevenK: I don't think that's valid.
[09:27] <wgrant> How does it create the delayedcopy?
[09:27] <StevenK> _autotest.distribution)
[09:27] <StevenK> Rargh
[09:27] <wgrant> And can you check the code that creates them in reality?
[09:27] <wgrant> To see if it sets it?
[09:27] <wgrant> Also, brb.
[09:28] <StevenK> wgrant: The test passes in self.test_publisher.person.gpg_keys[0] explicity
[09:28] <StevenK> *explicitly
[09:30] <bigjools> StevenK: mumble
[09:31] <StevenK> wgrant: Right, looks like the package copier sets the key to None, but a lot of tests set it to a key
[09:46] <wgrant> StevenK: Kill them.
[09:46] <wgrant> StevenK: Actually, probably best to work out why it worked before.
[09:46] <StevenK> wgrant: I have no idea :-(
[09:53] <wgrant> StevenK: You'd best work that out :/
[10:05] <bigjools> wgrant: don't we have code that stops account merges when someone has a PPA?
[10:07] <wgrant> bigjools: Yes.
[10:07] <wgrant> bigjools: It worked when I tried it last week, too.
[10:07] <wgrant> NFI what happened there.
[10:07] <bigjools> :/
[10:07] <bigjools> there will be an orphan repo
[10:07] <bigjools> which is a bit of a disaster if a new on gets created
[10:08] <wgrant> It's merged on DF.
[10:08] <wgrant> Let's see...
[10:08] <wgrant> It's disabled...
[10:09] <wgrant> status == 2
[10:09] <wgrant> The PPA is deleted.
[10:09] <wgrant> So the merge was OK.
[10:09] <bigjools> ah
[10:09] <wgrant> But the sub link shouldn't be shown.
[10:09] <bigjools> ok
[10:09] <StevenK> wgrant: Fixed, I think.
[10:09] <wgrant> StevenK: How?
[10:09] <StevenK> wgrant: Was a bug in notify()
[10:09] <wgrant> bigjools: Can you tell sladen so I can pretend to nearly keep to core hours? :)
[10:09] <bigjools> yeah PMing him now
[10:10] <StevenK> wgrant: The old code said "If pocket is SECURITY and there is no source", my code said "If pocket is SECURITY and there is source" ...
[10:10] <wgrant> StevenK: aaaaaaaa
[10:10] <wgrant> Pocket-specific hacks make me cry.
[10:10] <wgrant> And/or murderous.
[10:11] <wgrant> But yes, I know the one you mean.
[10:11] <jtv> ooh allenap, I have one for you!
[10:11] <allenap> jtv: Send it over :)
[10:12] <jtv> As soon as the #$%*&@ page will load.
[10:13] <jtv> allenap: https://code.launchpad.net/~jtv/launchpad/db-bug-786970/+merge/62292
[10:13] <LPCIBot> Project windmill-devel build #141: STILL FAILING in 1 hr 12 min: https://lpci.wedontsleep.org/job/windmill-devel/141/
[10:13] <jtv> Hmm it's still showing the conflicts.  But that should update any moment now.
[10:13] <StevenK> wgrant: So I think all tests pass now.
[10:14] <wgrant> StevenK: -vvt soyuz -t archiveuploader -t archivepublisher
[10:14] <StevenK> wgrant: I don't really want to tie up my machine for 50 minutes
[10:14] <wgrant> Yeah.
[10:14] <wgrant> ec2 it.
[10:14] <bigjools> and the rest
[10:15] <StevenK> bigjools: Speak for yourself, my machine runs -vmm soyuz in 29 minutes.
[10:15] <StevenK> -vvm, even
[10:15] <bigjools> StevenK: and archivepublisher, archiveuploader, builddmaster ? :)
[10:15] <StevenK> wgrant didn't say buildmaster
[10:16] <wgrant> buildmaster's not so relevant here.
[10:16] <bigjools> it'd be a good idea to run it though
[10:16] <wgrant> But still useful.
[10:16] <jtv> bigjools: should the UI allow the user to request a sync for a DSD that also has a DSDJob pending?  Probably not what you _want_, but don't know whether we should be difficult about it.
[10:16] <bigjools> it generates emails
[10:16] <wgrant> There may be one or two relevant tests.
[10:16] <StevenK> Anyway, ec2 is off
[10:16] <jtv> allenap: my diff's updated.  Conflicts are gone.
[10:16] <bigjools> jtv: it's a valid thing to do so don't prevent it
[10:16] <allenap> jtv: Cool. I've claimed it.
[10:16] <StevenK> wgrant: If it passes ec2, what's the next step?
[10:16] <jtv> thanks allenap
[10:17] <bigjools> jtv: which of course means there may be more than one DSDJ for the package
[10:17] <wgrant> StevenK: I will rereview it first thing tomorrow morning.
[10:17] <jtv> bigjools: yes, makes sense (otherwise parent updates could become a DoS condition :) though it introduces a slight asymmetry in the logic.
[10:17] <wgrant> StevenK: And attempt to restrain myself from asking you to split it.
[10:17] <StevenK> Hah
[10:17]  * bigjools starts looking at what info +queue and the queue tool need out of PackageCopyJob to work
[10:18] <wgrant> bigjools: Surely you wouldn't be insinuating that we don't have a nice clear, simple interface between the queue UI and the data model :)
[10:19] <bigjools> :/
[10:19] <bigjools> the queue page is already a nightmare.  this will make it a zombie nightmare
[10:20] <StevenK> And pitti was asking us yesterday to make it quicker
[10:20] <StevenK> :-)
[10:20] <wgrant> At least delayed copies are nearing their end.
[10:20] <bigjools> yay
[10:20] <bigjools> PCJ is the new delayed copy :)
[10:20] <wgrant> Except slightly less ugly.
[10:20]  * StevenK shoots self, allenap 
[10:20] <jml> Do we have a policy template (distinct from the process template, which I know we have)
[10:21] <jml> StevenK: tch tch. such violence is unnecessary.
[10:21] <allenap> StevenK: Why?
[10:21] <StevenK> allenap: [19:20] < bigjools> PCJ is the new delayed copy :) And PCJs are your fault :-)
[10:22] <StevenK> And delayed copies make me want to hurt people.
[10:22] <wgrant> bigjools: One day we will properly unify them.
[10:22] <wgrant> bigjools: But until then PCJ is a much less bad hack.
[10:22]  * bigjools is not responsible for delayed copies!
[10:22] <wgrant> I don't appreciate your lies.
[10:22] <allenap> StevenK: I blame Jelmer :)
[10:22] <bigjools> a certain Brazilian did them
[10:23] <StevenK> allenap: Actually, it's my fault! I told you how to do it quickly!
[10:23] <wgrant> I can understand why they were done, given time pressures and reuploading... but doesn't make me like them any more.
[10:23] <allenap> StevenK: Ah ha, that's why you were proposing to shoot yourself!
[10:24] <StevenK> I've been reading delayed copies code today, I'm suicidal
[10:24] <wgrant> StevenK: It's OK to think about delayed copies if you are doing it to remove them.
[10:26] <StevenK> Bleh, branch is now 1116 :-(
[10:26] <StevenK> It still removes more than it adds back
[10:26] <wgrant> At least you've done what LCD manufacturers have failed to do.
[10:27] <StevenK> What's that?
[10:27] <wgrant> Exceed the 1080p you were stuck at for a while.
[10:27] <StevenK> "lol"
[10:28]  * bigjools strokes his 1920x1200 24-incher
[10:29]  * StevenK stabs his eyes
[10:29] <StevenK> I've forgotten how to check resolution
[10:29] <wgrant> xrandr
[10:29] <StevenK> But I think this LCD is only 22 inches
[10:30] <StevenK> 1920x1080
[10:31] <bigjools> wgrant: so, the plan was to create a PU at the same time as a PCJ, right?
[10:31] <wgrant> bigjools: I think that is best for now.
[10:31]  * allenap gingerly pets his 2560x1600 30-incher.
[10:31] <bigjools> or did we talk about making the PCJ create the PU?
[10:31] <wgrant> allenap: !!
[10:31] <wgrant> allenap: I want one.
[10:31]  * bigjools drives to allenap's house with a lock pick and a shotgun
[10:31] <wgrant> 24" @ 1920x1080 is almost painfully low DPI.
[10:32] <wgrant> bigjools: How are PCJs normally created now?
[10:32] <StevenK> allenap: Which make and model?
[10:32] <bigjools> wgrant: in the browser code
[10:32] <StevenK> Hm, I wonder if X can spit out the EDID information
[10:32] <allenap> It's an Apple thingy, I'm not sure they sell 30" models any more. It's 4 years old.
[10:33] <wgrant> StevenK: xrandr --prop
[10:33] <StevenK> You said the magic A word that makes me lose interest.
[10:33] <allenap> Hehe :)
[10:33] <wgrant> bigjools: And the real permission checks are done at job execution time?
[10:33] <StevenK> wgrant: EDID isn't the make of model of the display?
[10:34] <bigjools> wgrant: yeah it would have to, as a backstop
[10:34] <wgrant> StevenK: It contains that information, plus the supported modes.
[10:35] <wgrant> bigjools: This is going to be ugly for a while :(
[10:35] <wgrant> Not sure how to do this efficiently...
[10:35] <bigjools> wgrant: s/for a while/
[10:35] <wgrant> bigjools: It can be cleaned up as tech-debt eventually.
[10:35] <wgrant> EVENTUALLY
[10:36] <wgrant> This is some tech-debt I am happy to tolerate for now, though.
[10:36] <wgrant> bigjools: We are moving to one PCJ per package, right?
[10:36] <bigjools> the form button is intelligently presented depending on whether you have permission but there's nothing to prevent url hacking to POST something it seems
[10:36] <wgrant> Right.
[10:36] <wgrant> That's sensible enough.
[10:36] <bigjools> wgrant: yes, one per package to make error reporting easier
[10:37] <bigjools> also so that mass-sync completes :)
[10:37] <wgrant> Yeah.
[10:37] <wgrant> So.
[10:37] <wgrant> What we want, I guess, is a quick bit of hackery to work out whether to create an UNAPPROVED or DONE packageupload.
[10:37] <wgrant> Since the autoapproval logic will have to be batched.
[10:37] <wgrant> And is currently lurking in the depths of Archiveuploader the Great.
[10:38] <bigjools> I already did the policy stuff
[10:38] <bigjools> just need to hook it into the PCJ
[10:38] <wgrant> Does it work?
[10:38] <bigjools> ...
[10:38] <bigjools> it's just the policy object
[10:38] <bigjools> it's not *used* yet
[10:38] <wgrant> Yes, but that doesn't mean it is completely working.
[10:39] <wgrant> eg. overrides aren't *quite* done yet.
[10:39] <bigjools> they're not done at all, until something uses the code in PCJ
[10:39] <bigjools> which sort of tells me that we probably need to create the PU in the PCJ
[10:39] <wgrant> The underlying logic is incompletely implemented.
[10:40] <bigjools> what logic?
[10:40] <wgrant> The override policies.
[10:40] <wgrant> No multiverse override, no way to handle newness, etc.
[10:40] <wgrant> Hee hee newness.
[10:40] <wgrant> We still have absolutely no way to handle that.
[10:40] <wgrant> But we'll see.
[10:40] <wgrant> And/or die.
[10:41] <jml> wgrant: newness is actually a perfectly cromulent word
[10:41] <wgrant> jml: It's also a good way to describe the demise of several of the grand plans.
[10:41] <bigjools> the newness has to come from the ancestry check
[10:41] <wgrant> But that is yet to be seen.
[10:41] <wgrant> bigjools: Sure, that's how we identify it.
[10:41] <wgrant> But we have no way to resolve it.
[10:41] <bigjools> that can now be hooked into the PCJ
[10:41] <bigjools> eh?
[10:42] <wgrant> You know how queue overrides are done, right?
[10:42] <bigjools> ...
[10:42] <wgrant> Queue overrides are required for NEWing.
[10:42] <wgrant> And queue overrides involve mutating the SPR and BPRs.
[10:42] <jtv> Grrr how do I get privileges to see +localpackagediffs on my local machine again?
[10:42] <henninge> Can somebody give me some help on vocabulary lookup?
[10:42] <wgrant> This doesn't work quite so well in a copying world.
[10:42] <bigjools> since I wrote a lot of the original code I do have some idea, yes
[10:42] <wgrant> jtv: The FF name changed yesterday. Check /+feature-info for hints.
[10:42] <bigjools> no, we don't ever, ever mutate SPR or BPR
[10:43] <wgrant> bigjools: orly.
[10:43] <wgrant> Let me find it for you.
[10:43] <bigjools> if it's happening somewhere it's a bug
[10:43] <wgrant> No, it's just terribly ufly.
[10:43] <wgrant> ugly.
[10:43] <bigjools> I changed some code once that did that, so it creates the publication properly
[10:43] <wgrant> lololol
[10:44] <wgrant> bigjools: PackageUpload.overrideSource.
[10:44] <wgrant> Calls SourcePackageRelease.override.
[10:44] <wgrant> Which you may not want to view without an empty stomach.
[10:44] <jtv> wgrant: ah great, somebody did something about the "-" issue
[10:44] <henninge> I have a lookup code like this in InlineEditPickerWidget: http://paste.ubuntu.com/613120/
[10:45] <henninge> The exported field is an "owner" from IHasOwner. Where is that vocabulary defined?
[10:45] <bigjools> wgrant: too late
[10:46] <wgrant> henninge: That's not a vocab.
[10:46] <wgrant> henninge: You'd normally use a variant of ValidPersonOrTeam for that.
[10:47] <henninge> wgrant: I don't understand. What is not a vocabulary?
[10:47] <wgrant> henninge: IHasOwner.
[10:47] <wgrant> Or owner, even.
[10:48] <bigjools> wgrant: so those overrides are only manual overrides
[10:48] <henninge> FTR, this is not code I wrode, I am just trying to understand existing code.
[10:48] <henninge> s/wrode/wrote/
[10:49] <henninge> wgrant: The widget gets instantiated like this: http://paste.ubuntu.com/613126/
[10:49] <henninge> wgrant: ISourcePackageRecipe inherits from IHasOwner
[10:49] <henninge> it does not define anything else for owner
[10:50] <henninge> wgrant: never mind, there it is in the interface
[10:50]  * henninge was blind again
[10:50] <wgrant> bigjools: Right, but you need manual overrides when you're NEWing.
[10:50] <bigjools> wgrant: we can make the PCJ code DTRT for non-NEW stuff as it won't hit the queue, but anything that is held and overridden will be a problem :(
[10:50] <henninge> UserTeamsParticipationPlusSelf
[10:51] <bigjools> wgrant: this is a nightmare.
[10:51] <wgrant> bigjools: Yes, that's what I said :)
[10:51] <wgrant> The demise of several of the grand plans.
[10:51] <bigjools> wgrant: I said it was a zombie nightmare :)
[10:51] <bigjools> we'll have to have different logic in the manual overrides if it's a PCJ
[10:52] <wgrant> Yes, but we have nowhere to put them.
[10:52] <bigjools> good point.
[10:52] <bigjools> shit
[10:52] <wgrant> Rather.
[10:52] <bigjools> we could dupe the SPR
[10:52] <wgrant> You're a bad person.
[10:52] <bigjools> :)
[10:53] <bigjools> it's no different to what happens when someone uploads manually
[10:53] <bigjools> but with no publishing records, wtf else can we do
[10:53] <wgrant> We'd have to store JSON overrides on the PCJ or something.
[10:56] <bigjools> hmmm
[10:56] <lifeless> did you just tell data integrity to go f**k itself bob?
[10:56] <bigjools> that means fixing process-accepted
[10:57] <wgrant> bigjools: Why is p-a affected?
[10:57] <wgrant> lifeless: Yes.
[10:57] <wgrant> lifeless: The proper fix for this is too big to consider now.
[10:57] <bigjools> because it creates publications, it'd need to read the json blob with the override
[10:57] <wgrant> lifeless: But it's not that hard for one person to retrofit in a week or so.
[10:57] <wgrant> I don't think.
[10:57] <wgrant> bigjools: No... PCJ creates the publications.
[10:57] <wgrant> bigjools: This is not delayed copies.
[10:58] <wgrant> bigjools: Your mind is tainted.
[10:58] <bigjools> not really
[10:58] <wgrant> p-a only creates publications for builds and delayed copies.
[10:58] <wgrant> PCJ will create these publications.
[10:58] <bigjools> ok so this is easy, as I first though.  You're the one dropping poison in my head
[10:59] <bigjools> thought*
[10:59] <wgrant> You still need some new way to store overrides on PCJ.
[10:59] <bigjools> nope
[10:59] <wgrant> Oh?
[10:59] <wgrant> How do you propose to do it?
[11:07] <henninge> lifeless: ping
[11:08] <lifeless> henninge: hi
[11:08] <henninge> lifeless: Hi, I'd like to discuss my options for fixing bug 778129
[11:08] <_mup_> Bug #778129: cannot change owner for recipe - picker shows 'undefined' <regression> <Launchpad itself:In Progress by henninge> < https://launchpad.net/bugs/778129 >
[11:09] <lifeless> shoot
[11:09] <henninge> lifeless: it seems that only few people are affected, namely those that have a lot of team participations.
[11:09] <henninge> The simplest solution would be to increase the number of batches
[11:09] <henninge> like from 20 to 30.
[11:10] <lifeless> I thought the problem was that 'big' was being assessed in two different ways
[11:10] <lifeless> like, there is one metric that defines 'huge'
[11:10] <henninge> The vocoabulary for this does not provide IHugeVocabulary and therefore no search box is displayed.
[11:10] <lifeless> and another that defines 'too many batches'
[11:11] <henninge> right, "huge" is by providing the interface
[11:11] <lifeless> so, can we provide the interface?
[11:11] <henninge> "too many batches" is a fixed literal in the js
[11:12] <henninge> we could but then everybody gets it, even if they are only in three teams ...
[11:12] <henninge> I mean , the search box.
[11:12] <lifeless> so
[11:12] <lifeless> perhaps a short + long term fix.
[11:13] <henninge> The most complex solution would be to first peek how many entries there are and only present the searchbox if it exeeds a limit.
[11:14] <henninge> yes, so my short term fix would be to increase the number of batches
[11:14] <lifeless> how many items per page ?
[11:14] <henninge> 6
[11:14] <henninge> i could increase that instead
[11:14] <lifeless> we need to show 230 items
[11:14] <lifeless> 38 pages
[11:15] <henninge> why 230?
[11:15] <lifeless> cody
[11:15] <henninge> ;-)
[11:15] <henninge> ok
[11:15] <lifeless> thats without a safety margin
[11:15] <lifeless> one thing I don't understand
[11:16] <lifeless> why don't we grab the first page of the vocab, *not* now a total batch, link to 'next' (not 2, 3, 4 etc) and if the first page of the vocab is filled up offer the serch box
[11:17] <lifeless> that seems to me like it would scale low (< 7 items would show a simple page), scale medium (click next a couple of times) and scale indefinitely (folk can search)
[11:17] <henninge> that would be my long-term solution.
[11:17] <lifeless> I don't know how much work this would be
[11:17] <henninge> The vocab needs to provide IHugeVocabulary because that gives search capability.
[11:18] <lifeless> yes, thats pretty easy
[11:18] <henninge> I know, just saying
[11:18] <lifeless> yeah, agreed.
[11:18] <lifeless> anyhow
[11:18] <henninge> lifeless: I will fix this bug with the short-term solution and file a bug for the complex solution.
[11:18] <lifeless> I have no particular view on whether we should invest in the long term solution right now.
[11:19] <lifeless> I do think that the inability to use the form is the crucial thing to address
[11:19] <henninge> I think it may also tie in with the broken search that was discussed
[11:19] <henninge> right
[11:19] <henninge> any form that uses this vocab
[11:21] <lifeless> its a little odd that the vocab is restricted as it is
[11:21] <lifeless> we used to be able to hand off objects to any user
[11:21] <lifeless> but perhaps I'm out of date
[11:21] <lifeless> certainly teams one is directly related too is a common case
[11:22] <henninge> yes, I think so
[11:22] <lifeless> thinking slightly bigger picture showing just some sensible teams and allowing a search of either 'my other teams' or 'all people in launchpad'
[11:22] <lifeless> would let things be more flexible
[11:22] <lifeless> e.g. the way I found this bug I was handing a recipe off to a new maintainer
[11:23] <lifeless> there was no expectation that there be a team in common
[11:23] <henninge> so this really should just be "any team or person"
[11:23] <henninge> ?
[11:23] <lifeless> so another way you could fix this is to change the vocab
[11:24] <henninge> good point
[11:24] <lifeless> I would consult with sinzui, as master of all abandonded objects
[11:24] <wgrant> In this case it's critical that it be limited to teams of which you are a member.
[11:24] <wgrant> It's used for privilege checking for daily builds.
[11:24] <lifeless> wgrant: how so?
[11:24] <lifeless> huh?
[11:24] <wgrant> lifeless: The requester of a daily build is the recipe owner.
[11:25] <wgrant> The requester is used for privilege checking on the archive.
[11:25] <lifeless> do you mean 'the only valid owners of the recipe are folk that can upload to the archive' ?
[11:26] <wgrant> Launchpad impersonates the recipe owner when scheduling daily builds.
[11:26] <wgrant> So setting the recipe owner is delegating impersonation rights.
[11:26] <wgrant> So it must only be done by a member of the team selected.
[11:26] <lifeless> hang on
[11:27] <lifeless> the dots aren't joining
[11:27] <lifeless> I get why we can't use anyone
[11:27] <StevenK> wgrant: archiveuploader tests are broken :-(
[11:27] <wgrant> StevenK: TYS
[11:27] <wgrant> StevenK: But howso?
[11:27] <lifeless> but both henninge and I can upload to the lp ppa
[11:27] <lifeless> why can't I make a recipe and hand it over to him ?
[11:27] <wgrant> lifeless: Because that would be impersonating him.
[11:27] <StevenK> wgrant: Wrong number of recipents
[11:27] <wgrant> StevenK: Yay
[11:28] <StevenK> reference = ['Foo Bar <foo.bar@canonical.com>', 'Foo Bar <foo.bar@canonical.com>']
[11:28] <StevenK> actual = ['Foo Bar <foo.bar@canonical.com>']
[11:28] <wgrant> Hahaha
[11:28] <lifeless> wgrant: who does it impersonate when the owner is a team ?
[11:29] <wgrant> lifeless: You have an anthropomorphised team.
[11:30] <lifeless> wgrant: then I'm missing the issue
[11:30] <lifeless> if the impersonation is checking permissions
[11:30] <wgrant> Hmm?
[11:30] <wgrant> If I set the daily build archive of a recipe I own to be the OEM primary archive, it will fail because I can't upload to the OEM primary archive.
[11:31] <lifeless> and the selection of owner is limited to entities with upload on the archive, and I have upload permission as well.
[11:31] <StevenK> wgrant: You think those are buggy tests?
[11:31] <lifeless> wgrant: right, it shouldn't let you set it to that archive.
[11:31] <wgrant> lifeless: Mm, I guess......
[11:31] <wgrant> StevenK: I'd work out why it wants a duplicate.
[11:31] <lifeless> wgrant: I'm spotting an inconsistency here is my point:
[11:31] <wgrant> StevenK: You probably do have a bug in your code.
[11:31] <wgrant> StevenK: But the test is also clearly crap.
[11:32] <lifeless>  - the teams I'm in are not the same as 'folk with upload access to the archive'
[11:32] <lifeless>  - because those teams are not me, and only *some* of them may grant upload access to the archive
[11:32] <lifeless>  - so limiting it to those teams does not make sense
[11:33] <lifeless>  - limiting the selection to entities that *do* have upload access to the archive would make sense, but to prevent privilege escalation I must also have said access.
[11:33] <lifeless> right now, I can select a broken team as easily as a working one.
[11:34] <wgrant> We'd need to think about how restricting those would work.
[11:34] <wgrant> It may make some moves impossible.
[11:34] <lifeless> I put it to you the right vocab is ICanUploadToArchiveButEmptyIfICannot
[11:34] <wgrant> Needs thought.
[11:34] <wgrant> Probably.
[11:35] <lifeless> it would make a move impossible where there isn't a common archive that the source and target can both upload to
[11:35] <lifeless> to do that move would need a handshake rather than a simple assignment
[11:35] <lifeless> henninge: does anything else use the vocab ?
[11:36] <lifeless> henninge: and have you followed this chatter?
[11:36] <henninge> at first I did ...
[11:36]  * henninge reads rest
[11:37] <lifeless> wgrant: we could say 'anyone with upload if I have upload, or any team I'm in if I don't have upload' - but thats just an ugly way of permitting a hand-shake to do arbitrary moves.
[11:38] <lifeless> wgrant: I think at the point you want to change trust boundaries like that its better to say to folk 'copy the recipe text across and delete the old one'
[11:39] <henninge> let me check on the vocab
[11:40] <gmb> allenap: Hola. Can you take a look at https://code.launchpad.net/~gmb/launchpad/conjoined-oops-bug-106338/+merge/62456 for me?
[11:41] <lifeless> brb
[11:41] <allenap> gmb: Sure. I'm looking at a branch for Jeroen right now, but I'll do your's right after that.
[11:41] <gmb> Ok. No rush.
[11:42] <allenap> gmb: I have a sneaking suspicion that the apostrophe was unwarranted.
[11:43] <gmb> allenap: I'll forgive you THIS ONCE.
[11:43] <allenap> Thank you :)
[11:44] <henninge> lifeless: it's also used for Branch and BranchMergeQueue
[11:44] <henninge> lifeless: anyhhow, I think that discussion is about  a different bug then what I am trying to fix here.
[11:45] <henninge> I will go with the short-term/long-term solution that we discussed.
[11:45]  * henninge has to change locations now
[12:04] <bigjools> wgrant: you've got mail
[12:04] <wgrant> Forboding.
[12:05] <wgrant> Is it like 100MB or something?
[12:06] <mwhudson> that's kind of a redundant thing to say to a canonical employee
[12:07] <wgrant> Hm, only 616KB.
[12:07] <wgrant> Why did it take 2 minutes to download? :/
[12:08] <wgrant> bigjools: Why "in different distro"?
[12:08] <wgrant> bigjools: PPA -> primary copies should be queued too.
[12:08] <wgrant> bigjools: Hm, so the job will run twice?
[12:08] <cjohnston> henninge-lunch: I'm around when you get back.
[12:09] <bigjools> wgrant: yes it needs to run twice
[12:09] <bigjools> otherwise webapp requests need to start checking policy and ancestry
[12:09] <wgrant> Ah, I didn't read your prose.
[12:09] <wgrant> That makes sense.
[12:09] <wgrant> I was hoping I could think of a way around that.
[12:09] <wgrant> But I cannot right now.
[12:09] <wgrant> Ew @ json_data, but it will work.
[12:09] <wgrant> doit.
[12:11] <lifeless> jml: I think talking at the very end of my day gets into rambling conversations.
[12:12] <jtv> allenap: I'll be away now, so will have to follow up on that review tomorrow.
[12:12] <lifeless> jtv: sorry
[12:12] <lifeless> jtv: I just cleared my plate !
[12:12] <lifeless> jtv: but its really late.
[12:12] <lifeless> jtv: lets talk your morning?
[12:12] <jml> lifeless: heh
[12:12] <jml> lifeless: certainly is the case with me.
[12:12] <jtv> lifeless: never mind, it's not needed now!  Will explain another time if desired.
[12:13] <lifeless> sure
[12:13] <allenap> jtv: Okay, have a good evening. Fwiw, I'll be finished in less than 5 minutes.
[12:13] <jtv> Ooh@
[12:13] <jtv> @
[12:13] <jtv> !
[12:13] <jtv> such temptation.
[12:13] <jtv> But that's how it always goes.  "Just this one more, darling"
[12:13] <jtv> And then there's yet another bug to fix, another branch to land.
[12:14] <jml> any maint squad folk around to deal w/ doko's problem?
[12:23] <lifeless> jml: I'm not sure I've made sense in my latest mail; be generous reading it :)
[12:24] <lifeless> also python 3 upstream attitude about bytes vs unicode really is starting to depress me
[12:25] <jml> what's their attitude?
[12:25] <lifeless> it seems to be 'its appropriate for it to be hard to work with bytes, because bytes are not unicode/text'
[12:25] <jml> lifeless: it does make sense, thanks. still thinking about the answer to the "where to capture?" question
[12:26] <lifeless> the latter I agree with, the conclusion bogus
[12:26] <lifeless> jml: [back to bytes]
[12:28] <lifeless> ok gnight
[12:50] <wgrant> allenap: Ah, nice, we have the actual rabbit log this time!
[12:52] <LPCIBot> Project db-devel build #582: STILL FAILING in 4 hr 58 min: https://lpci.wedontsleep.org/job/db-devel/582/
[12:53] <henninge-lunch>  /nick henninge
[12:57] <henninge> Hi cjohnston!
[13:01] <allenap> wgrant: Yes, at last :)
[13:03] <cjohnston> hey henninge
[13:06] <henninge> cjohnston: hang on, I am preparing something
[13:06] <cjohnston> yup
[13:07] <jml> mrevell: strikethrough doesn't work on the dev wiki. where should I file the bug?
[13:12] <henninge> cjohnston: are you familiar with doctests and how to read them or would you like me to explain?
[13:13] <henninge> cjohnston: also, we can do this in voice, if you prefer that ;-)
[13:13] <cjohnston> That would be fine.
[13:13] <cjohnston> I'm guessing at it, but I think I'm doign ok
[13:13] <henninge> which of the two? ;-)
[13:13] <cjohnston> explain and voice ;-)
[13:15] <henninge> cjohnston: I only have our internal Mumble server set up, the other option is skype.
[13:22] <LPCIBot> Project windmill-devel build #142: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/142/
[13:24] <henninge> cjohnston: one thing I saw that may be confusing is that one of the tests is run four times.
[13:24] <henninge> that's a bug in our test suite
[13:24] <cjohnston> ok
[13:24] <wgrant> henninge: Are you sure? It's not run once for each implementation of an interface?
[13:25] <henninge> wgrant: it's a doctest
[13:25] <henninge> bugnotificationrecipients.txt
[13:25] <henninge> wgrant: http://paste.ubuntu.com/613205/
[13:26] <wgrant> henninge: Ah, it's run in four different DB users.
[13:26] <henninge> ah, ok
[13:26] <henninge> I remembered jtv reporting tests being run multiple times
[13:26] <henninge> anyway
[13:27] <henninge> cjohnston: we'll only have to deal with it once, though.
[13:27] <cjohnston> ok.. cool
[13:27] <henninge> cjohnston: but first I have this: http://paste.ubuntu.com/613206/
[13:28] <henninge> that's the output of the other two failing doctests. I pasted it so we have linen numbers to talk about.
[13:28] <cjohnston> ok
[13:28] <henninge> cjohnston: doctest will output a lot of context that is not really failing but look like it.
[13:29] <cjohnston> my thought is  ^^^^^^^^^^^^ is what we are looking at?
[13:29] <henninge> in this case, the actual failure is on lines 87-89
[13:29] <cjohnston> ok.. so I was in the right area atleast
[13:30] <henninge> the other differences it points out is where it matched '...' to '--' on the page.
[13:30] <henninge> do you have a local copy of the branch?
[13:31] <henninge> well, you should
[13:31] <cjohnston> yes
[13:31] <henninge> so, in lib/lp/bugs/doc/bugnotification-sending.txt line 68 is where this starts
[13:31] <henninge> that's what line 24 in the diff tells us
[13:32] <henninge> scrolling down, line 123 is where the text needs to be adapted to the new wording
[13:33] <cjohnston> so just s/xx/xx to make it match?
[13:33] <henninge> right
[13:34] <henninge> doctests don't care about line breaks, so you can fit it nicely in the 78 columns limit
[13:34] <cjohnston> ok.. That one is done.
[13:35] <henninge> cool, next one
[13:35] <henninge> line 323
[13:35] <henninge> (line 101 of the diff)
[13:35] <cjohnston> yup
[13:36] <henninge> you are aware of the meaning of '...'
[13:36] <henninge> ?
[13:36] <henninge> It just maches any text
[13:36] <cjohnston> no
[13:36] <cjohnston> ok
[13:37] <henninge> line 105 of the diff shows you what the test saw, starts with a '+'
[13:37] <henninge> lines 106-114 show you what it expected
[13:37] <cjohnston> right.
[13:37] <henninge> that's from the doctest line 324...
[13:38] <henninge> The first one starts with [...
[13:38] <henninge> so there it eats any text it finds until the next text fits
[13:38] <cjohnston> http://paste.ubuntu.com/613218/
[13:39] <henninge> For this array literal it means ignoring the first elements until the '-- ' element.
[13:39] <gmb> allenap: Thanks for t'review. I'll make the change you suggest.
[13:40] <henninge> cjohnston: perfect!
[13:40] <henninge> ... and here I am explaining
[13:40] <henninge> ;-)
[13:40] <cjohnston> well.. learning what the stuff means is more helpful than just being able to s/xx/xx
[13:41] <henninge> right
[13:41] <henninge> ;)
[13:41] <cjohnston> so the next issue is 152 of the diff?
[13:41] <henninge> yup
[13:41] <cjohnston> bugnotification-sending.txt 437
[13:41] <henninge> right
[13:42] <mrevell> jml, https://bugs.launchpad.net/launchpad-dev-moin-theme/
[13:42] <henninge> cjohnston: bug line 162 of the diff also says that it is missing the unsubscribe footer.
[13:42] <henninge> hm
[13:43] <cjohnston> I don't understand what 173/175 means
[13:43] <henninge> cjohnston: there is a ... that is replaced by an 18
[13:44] <henninge> it's not a failure although the output makes it look like one
[13:44] <cjohnston> ok
[13:44] <cjohnston> so the test is bug 18 I guess?
[13:44] <_mup_> Bug #18: RFE: I'd like to be CC:d automatically to bugs I report <feature> <lp-bugs> <Launchpad itself:Fix Released by bradb> < https://launchpad.net/bugs/18 >
[13:44] <henninge> the test does not care about the bug number, that's why the ... is there
[13:44] <henninge> but when the test is run it happens to be 18, yes.
[13:45] <cjohnston> ok
[13:45] <henninge> line 184 is the actual failure
[13:45] <cjohnston> right.
[13:45] <henninge> and line 196 is ok, just a trailing ... to leave the dummy text out of the test.
[13:46] <cjohnston> ok
[13:46] <cjohnston> the next one I'm kinda condused about.. starting at 201
[13:46] <henninge> yeah, I was just wondering waht's going on there
[13:49] <jml> mrevell: thanks.
[13:49] <henninge> cjohnston: I am not quite sure but it seems the test runner is getting mixed up a bit.
[13:50] <henninge> I would let this one be for now and go to the next one.
[13:50] <cjohnston> ok
[13:50] <henninge> once we fix all places that we can spot, we can re-run the test and see if it fits now.
[13:50] <henninge> the next one is line 242 of the diff
[13:51] <henninge> cjohnston: I mean, you know what you changed and it should not affect anything else.
[13:52] <henninge> Just look for where those phrases appear and adapt them in the test.
[13:52] <henninge> line 272
[13:53] <henninge> line 322
[13:53] <cjohnston> I'm up to 400
[13:53] <cjohnston> ;-)
[13:53] <henninge> cool
[13:53] <henninge> 419, actually ;)
[13:53] <cjohnston> there isnt anything wrong with 416 is there?
[13:54] <henninge> no, it appears on 421
[13:54] <henninge> it's just different line wrapping in the test and the actual output.
[13:54] <henninge> once all the text fits, the line wrapping is ignored, as it should be.
[13:58] <cjohnston> I almost wonder if it should be "which is subscribed to this bug report."
[13:58] <bigjools> would anyone care to have a pre-imp chat with me about a change to the Job system?
[14:00] <bigjools> just the man
[14:00] <henninge> cjohnston, bigjools: we are having our team call now ;)
[14:01] <bigjools> abentley: good morning.  When you have a moment can I have a chat with you about a change I would like to make the Job system?
[14:01] <cjohnston> henninge: I'm down to line 1263 looking for anything else. how do I fix those? just edit unsubscribe to Edit Subscription?
[14:01] <abentley> bigjools: sure.  I'll be free in a few minutes.
[14:01] <bigjools> abentley: thanks.  shouldn't take long
[14:02] <henninge> cjohnston: re-run the test when you are done to see if anything else fails
[14:02] <henninge> bin/test -vvt bugnotification-sending.txt
[14:12] <cjohnston> henninge: I have no idea how/where to do that
[14:12] <henninge> cjohnston: run the test?
[14:13] <henninge> cjohnston: is that what you mean?
[14:13] <cjohnston> yes
[14:14] <henninge> do you have a working launchpad setup or were you just working on the branches?
[14:14] <jml> off for lunch
[14:14] <cjohnston> just working on branches
[14:14] <cjohnston> I thought just editing text wouldn't be a big deal.. I guess I was wrong. ;-) lol
[14:15] <cjohnston> https://code.launchpad.net/~chrisjohnston/launchpad/land-chrisjohnston-187013-197793-483373
[14:15] <henninge> yeah, Ill run the test for you, np.
[14:16] <cjohnston> Do I want to know what all of those things that got added in my branch are?
[14:18] <henninge> what things?
[14:18] <cjohnston> if you look at that branch theres 20 files added
[14:18] <cjohnston> http://bazaar.launchpad.net/~chrisjohnston/launchpad/land-chrisjohnston-187013-197793-483373/revision/13047
[14:20] <henninge> what did you do to get this branch?
[14:20] <cjohnston> I just merged in your branch made the changes and pushed back
[14:20] <henninge> right
[14:21] <henninge> my branch is based on a current (at the time) devel, so merging my branch pulls in all the changes that have been merged since you branched devel.
[14:21] <StevenK> wgrant: ec2 returned -- it is only the seven archiveuploader tests.
[14:21] <wgrant> StevenK: Good news.
[14:21] <henninge> cjohnston: You can ignore those but you should have committed after merging.
[14:22] <henninge> bzr merge lp:...
[14:22] <henninge> bzr commit -m"Merged such-and-such"
[14:22] <cjohnston> ok
[14:23] <henninge> or in this case it actually would have been best to just create a new branch from my branch.
[14:23] <henninge> bzr branch lp:~henninge/launchpad/land-chrisjohnston-187013-197793-483373
[14:24] <henninge> if you could do that and then manually copy the changes to the doctest into that branch, I think it would be cleaner.
[14:24] <cjohnston> working on it
[14:24] <henninge> I mean, just copy the doctest file you changed.
[14:24] <cjohnston> yup
[14:25] <henninge> and then do "push --overwrite" if you want to continue using the branch name.
[14:25] <cjohnston> ok
[14:33] <abentley> bigjools: I'm free to chat.
[14:33] <bigjools> abentley: great, mumble?
[14:33] <abentley> bigjools: sure.
[14:39] <cjohnston> henninge: https://code.launchpad.net/~chrisjohnston/launchpad/land-chrisjohnston-187013-197793-483373
[14:44] <henninge> cjohnston: still failing but less. Let me see what might be going wrong.
[15:22]  * henninge aims at deryck ....
[15:22] <henninge> ... POW! http://paste.ubuntu.com/613269/
[15:22] <deryck> henninge, on call, just a minute
[15:23] <henninge> deryck: nm, you're dead
[15:23] <henninge> cjohnston: that ^^ is the reason why the unsubscribe link is missing.
[15:24] <bigjools> abentley: should the new exception handler do anything with incomplete_jobs?
[15:25] <abentley> bigjools: Yes, when a job is suspended, it should be added to incomplete_jobs.
[15:26] <bigjools> ok thanks
[15:26] <cjohnston> henninge: I'm not sure I understand whats wrong
[15:28] <henninge> cjohnston: that code is searching for "direct subscriber"  in order to determine if it should add the unsubscribe link.
[15:28] <cjohnston> ok
[15:29] <henninge> like the XXX correctly points out, that is not a good way because it is fragile.
[15:29] <henninge> like we saw now - change the wording, and it breaks.
[15:30] <cjohnston> ya.. So maybe if 'subscribed to the bug' and not 'member of' ?
[15:35]  * jcsackett is starting to hate his computer.
[15:43] <bigjools> abentley: when you're ready -> https://code.launchpad.net/~julian-edwards/launchpad/suspend-running-jobs-bug-788612/+merge/62494
[15:43] <abentley> bigjools: ack
[15:43] <bigjools> thanks
[15:47] <cjohnston> henninge: https://code.launchpad.net/~chrisjohnston/launchpad/land-chrisjohnston-187013-197793-483373
[15:50] <henninge> cjohnston: yup, that's the fix
[15:50] <cjohnston> :-)
[15:52] <henninge> cjohnston: there is still a failure  in line 178 http://paste.ubuntu.com/613283/
[15:52] <henninge> an lingering " a"
[15:53] <henninge> s/an/a/
[15:54] <cjohnston> pushed
[15:55] <henninge> cool, bugnotification-sending.txt is passing now! ;-)
[15:58] <henninge> cjohnston: here is how "subscribing.txt" is failing
[15:58] <jcsackett> sinzui: chat?
[15:59] <henninge> http://paste.ubuntu.com/613288/
[15:59] <sinzui> jcsackett: yes
[16:00] <cjohnston> henninge: s/Unsubscribe/Edit Subscription?
[16:00] <henninge> cjohnston: right! I was trying to remember what might have changed here ... ;-)
[16:00] <cjohnston> I'm not sure totally how to read this one
[16:02] <deryck> henninge, hi.  ready for our call when you are.
[16:02] <henninge> deryck: one moment
[16:02] <deryck> henninge, np
[16:03] <cjohnston> >>> unsubit = browser.getControl(name='unsubscribe')  what are the requirements for that? is 'Edit Subscription' valid?
[16:03] <cjohnston> wait... that should be unsubscribe
[16:03] <henninge> cjohnston: well, the remaining failures may just be results of the initial failure. That is one of the problems with doctests.
[16:03] <henninge> let's see if the test passes with that first fix ...
[16:04] <cjohnston> pushed
[16:05] <henninge> it's "Update Subscription"
[16:06] <cjohnston> I changed it, you would think I would know that.. lol
[16:06] <cjohnston> done
[16:09] <henninge> cjohnston: there is one more getLink('Unsubscribe')
[16:09] <henninge> cjohnston: I have to be otp now.
[16:10] <cjohnston> ok
[16:10] <cjohnston> henninge: your talking about line 105? The way the text reads is that is the button that you click to unsubscribe no?
[16:24] <henninge> cjohnston: ok, back
[16:24] <cjohnston> :-)
[16:24] <henninge> line 105 is clicking on the link, then the test browser goes the next page and finds the actual unsubscribe button.
[16:25] <henninge> so line 105 needs to be updated for the test to pass
[16:25] <cjohnston> ok
[16:27] <jcsackett> deryck: would you have an opportunity to talk javascript picker with me by any chance?
[16:28] <deryck> jcsackett, I've been on calls non-stop since I logged on.  Can we wait 30 minutes to and hour and let me wrap a couple loose ends first?
[16:28] <cjohnston> done henninge
[16:28] <deryck> if you're blocked and it's critical, I can manage the time.
[16:29] <jcsackett> i'm semi-blocked, but i can certainly wait 30 minutes to give you a rest.
[16:29] <henninge> cjohnston: passing ;-)
[16:29] <gary_poster> allenap, you around?
[16:29] <jcsackett> i'll ping you again in a bit then, deryck. thanks in advance.
[16:29] <allenap> gary_poster: Yeah, hi.
[16:29] <allenap> Got a branch for me?
[16:30] <deryck> jcsackett, thanks.  and it's not rest.  :-)  I need to finish somethings from the calls before I loose the thought or note. ;)
[16:33] <gary_poster> hey allenap.  No, this is more in line of "picking malone dev's brain." :-) Do you happen to know anything about how we process incoming mail for comments?  In particular, do you know if we honor SPF records when we are processing mail?  Context: someone has had their account suspended because the account is being used to send spam.
[16:33] <gary_poster> They say they do not use web mail, and only use kubuntu, and have SPF records for their domain, so I am trying to see if I can give a scenario for this happening other than "your box or your webserver have probably been hacked, sorry."
[16:34] <henninge> cjohnston: here is the output for bugnotificationrecipients.txt http://paste.ubuntu.com/613310/
[16:34] <allenap> gary_poster: I have no knowledge that we check SPF in Launchpad. Martin Pool is probably the most versed in Launchpad's mail code right now, but I suspect SPF would be a question for the LOSAs or IS.
[16:35] <gary_poster> ok cool, thanks allenap
[16:35] <henninge> cjohnston: Thats all just replacements of the wording, towards the end of each section.
[16:35] <henninge> easy ;)
[16:38] <henninge> cjohnston: and finally http://paste.ubuntu.com/613313/
[16:39] <henninge> The error is on line 22. It's searching for "duplicate bug (17)" but now it's "duplicate bug report (17)"
[16:40] <henninge> line 20 of the diff tells you that it fails on line 62 of the test
[16:41] <abentley> bigjools: r=me.  I would call it "SuspendJob", not "SuspendJobError", because it's one of those rare exceptions that doesn't indicate an error.
[16:41] <henninge> cjohnston: EOD for me. Just push what you got and email me a reminder, I will take care of it tomorrow.
[16:42] <bigjools> abentley: yeah I thought about that one, I just wanted it to "look" like an exception
[16:42] <cjohnston> Thanks henninge
[16:42] <cjohnston> Have a good night!
[16:42] <bigjools> abentley: I'll change it, thanks
[16:42] <bigjools> abentley: although, SuspendJob looks like a type of Job :)
[16:42] <abentley> bigjools: SuspendJobException?  Anyhow, no big deal.
[16:43] <bigjools> yeah that's better
[16:46] <jml> good grief
[16:46] <jml> thunder
[16:46] <jml> in London
[16:47] <timrc> Noticed the topic in #launchpad-reviews.  Is this a permanent change?  If so, can someone please change #launchpad-reviews to #launchpad-dev in Step1, https://dev.launchpad.net/PatchSubmission
[16:51] <henninge> cjohnston: you have a good day ;-)
[16:51] <cjohnston> Thanks :-)
[16:52] <timrc> bigjools (+ friends), I'm looking at #724740... before I talk about my implementation idea, I've noticed (what seems to be) an inconsistency with how we set buildd_secret... in lib/lp/soyuz/model/archive.py we use create_unique_token_for_table(20, Archive.buildd_secret) whereas in lib/lp/soyuz/browser/archive.py we use "create_token(16)... should that not be create_token(20) or visa-versa ?
[16:52] <_mup_> Bug #724740: setting a ppa private cannot be done over the API <api> <oem-services> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/724740 >
[17:01] <bigjools> timrc: yeah they could be the same, it doesn't really matter though.
[17:01] <timrc> bigjools, ah ok
[17:01] <bigjools> it's just the length of the auto-generated password
[17:01] <bigjools> and it's not about size, it's about what you do with it :)
[17:01] <timrc> bigjools, lol
[17:01] <timrc> allenap, jcsackett: do you have some time today to discuss #724740 ?
[17:01] <_mup_> Bug #724740: setting a ppa private cannot be done over the API <api> <oem-services> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/724740 >
[17:01] <jcsackett> timrc: the ppa machinery is well out of my experience, i'm afriad. you would be better served with someone else. not sure about allenap, but i think he's approaching the end of his day.
[17:01] <jcsackett> deryck: had enough time to collate your thoughts from earlier calls?
[17:01] <timrc> jcsackett, okay :) so who are your ppa gurus and do you guys rotate the ocr responsibility?
[17:01] <timrc> is there a schedule that I can view so I know when to nag
[17:01] <deryck> jcsackett, yes.  5 more minutes.  I'm only marveling at my new found net fame.  But need to grab a coke.
[17:01] <bigjools> jcsackett: you don;t need to know anything about PPAs, it's about setting a property over the API that we don't want all and sundry to do
[17:01] <jcsackett> bigjools: ah, i see.
[17:02] <jcsackett> timrc: i probably can help with that, but i'm about to be otp and then out for a bit. i can ping you later to talk about API stuff, if you like.
[17:02] <allenap> timrc: Sorry, I have almost no PPA knowledge, and I will be afk in a short while too.
[17:02] <jcsackett> timrc: off the top of my head, i believe benji might be able to help you out if you need assistance ASAP, though i don't know about his current availability.
[17:03] <timrc> the change as I see it basically making the private attribute on IArchivePublic read-only, creating a mutator for it (e.g. setPrivate), and then placing the validator code into this mutator along with the logic to set the private attribute and the buildd_secret if it does not exist
[17:03] <jcsackett> perhaps ASAP isn't quite right, given that. :-P
[17:03] <timrc> (and the ppa was set to private)
[17:04] <bigjools> timrc: that sounds ok to me, what would the validator look like?
[17:04] <bigjools> ie. who can do it? :)
[17:06] <deryck> jcsackett, drag me where you want or meet me in orange.
[17:06] <jcsackett> deryck: mumble is apparently rejecting my password. one sec.
[17:06] <deryck> jcsackett, np
[17:06] <timrc> bigjools, the validator is the exact same validator that's currently used on the property
[17:07] <bigjools> timrc: ok, and the zope security will ensure it's only commercial admins who can do it
[17:07] <timrc>  bigjools, e.g: _validate_archive_privacy
[17:10] <timrc> bigjools, ok, well I'm going to assign the bug to me and proceed with the implementation if that's okay with you
[17:11] <bigjools> timrc: sounds great
[17:11] <bigjools> thanks for contributing
[17:12] <jml> I'm going offline for a bit. Will see you all tomorrow, most likely.
[17:12] <bigjools> circular imports BLOW
[17:15] <jml> yeah, it's a glitch in Python.
[17:15] <bigjools> or, I am being a moron
[17:16] <jml> Hmm. I've had the same issue.
[17:16] <jml> What version are you using?
[17:16] <bigjools> nothing to see here, move along
[17:17] <jml> loggerhead         14
[17:17] <jml> launchpad-buildd    3
[17:17] <jml> launchpadlib        2
[17:17] <jml> lazr.delegates      1
[17:17] <jml> oops-tools          1
[17:22] <jml> bye for real.
[17:22] <bigjools> cheerio
[17:29] <LPCIBot> Yippie, build fixed!
[17:29] <LPCIBot> Project db-devel build #583: FIXED in 4 hr 36 min: https://lpci.wedontsleep.org/job/db-devel/583/
[17:36] <LPCIBot> Project windmill-db-devel build #327: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/327/
[17:43] <jkakar> It's sad that price is coming as a reason to use GitHub over Launchpad (for private projects).
[17:44] <jkakar> It'd be nice if Launchpad just set the prices to the same as GitHub.
[17:53] <bigjools> can anyone think of any SQLObject model classes that have a FK to a StormBase model class?
[17:59] <sinzui> bigjools: Nothing comes to mind
[18:00] <bigjools> well I am trying to do just that and getting:
[18:00] <bigjools> PropertyPathError: Path 'PackageCopyJob.<primary key>' matches no known property.
[18:00] <bigjools> where PackageCopyJob is the FK table
[18:25] <abentley> I mean https://code.launchpad.net/~abentley/launchpad/handle-concurrent/+merge/62511
[19:07] <abentley> sinzui: I am looking at bug #595166.  ISTM that the root issue is that we expect process-mail to have new messages as its input, not existing ones.  Shouldn't it discard messages that are dupes?
[19:07] <_mup_> Bug #595166: IntegrityError raised filing a bug using the email interface <easy> <email> <lp-bugs> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/595166 >
[19:11] <abentley> deryck[lunch]: pre-implementation call when you're back?
[19:14] <jcsackett> abentley: sorry for the delay, looking at your branch now.
[19:15] <abentley> jcsackett: s'okay.
[19:15] <sinzui> abentley: I am re reading.this to remember is this really is a spam issue
[19:16] <abentley> sinzui: I don't see this being a spam issue unless an identical spam message gets sent to bugs twice.  Non-identical messages with the same msgid produce different messages.
[19:16] <sinzui> abentley: I think we really do want to discard messages from dupes
[19:17] <abentley> sinzui: cool, thanks.
[19:17] <sinzui> abentley: I investigate three cases. All were different messages with differnt spam links from different people, but the message ids were the sam
[19:17] <sinzui> same
[19:18] <abentley> sinzui: Was the original message spam, or had the content changed?
[19:18] <sinzui> yes the orginal was spam.
[19:18] <abentley> sinzui: cool.
[19:18] <sinzui> no client/process should reused an id, so if someone stole another users legitimate message, we want to reject that oo
[19:18] <sinzui> too
[19:30] <benji> anyone have pointers to how mailing lists work in LP?  I have a user that isn't getting emails he sends to the list
[19:30] <benji> perhaps user's don't get their own messages?
[19:34] <sinzui> benji: I can help
[19:34] <sinzui> benji: 1. verify lp shows he is subscribed.
[19:35] <benji> sinzui: https://launchpad.net/~syncany-team/+mailing-list-subscribers shows him as subscribed
[19:35] <sinzui> benji: 2. verify he is sending with a registered email address (lp rejects those it does not know about)
[19:35] <benji> he is
[19:36] <sinzui> benji: 3. is the message in the archive? This is dodgy because there can be a backlog
[19:36] <benji> an unrelated CHR question: is hiding non-spam comments at the commentor's request ok? (he was confused when he commented and doesn't want to spread confusion)
[19:36] <sinzui> wow, the empty archive view is bad...
[19:36] <benji> re. archive: not yet
[19:36] <sinzui> I think there means something else
[19:37] <benji> I was wondering if LP and MM aren't in sync
[19:37] <sinzui> I tested an empty archive view a few weeks ago. I it pretty
[19:38] <sinzui> benji: I think you are right. when we call create list, the archive is setup and we expect 2 index pages
[19:38] <sinzui> date and thread
[19:39]  * sinzui reads code to learn the order of events.
[19:40] <sinzui> oh, we create the directory, but do not call mhonarc because there is nothing to do
[19:40] <benji> sinzui: he just said that the first message showed up (https://lists.launchpad.net/syncany-team/)
[19:41] <sinzui> benji: regardless of nhonarc, we know that mm knows about the list because it made the dir and it sent back the success message
[19:41] <jcsackett> abentley: r=me, with a comment on the MP.
[19:42] <abentley> jcsackett: thanks!
[19:42] <jcsackett> benji: it's fine to hide a confused comment at the commentor's request.
[19:42] <jcsackett> the control was changed to "Hide comment" for precisely that reason. spam is not the only reason we hide things.
[19:43] <benji> jcsackett: great! thanks
[19:48] <jcsackett> sinzui: have a few moments to chat?
[19:48] <sinzui> benji, I was going to point you to a bug about the delay in the mailing list archive, but I do no see it.
[19:48] <sinzui> jcsackett: I can talk
[19:48] <sinzui> mumble or sip?
[19:49] <jcsackett> i'm good with either. are you already on mumble?
[19:49] <benji> sinzui: no problem, thanks for all your help!
[20:51] <lifeless> mornink
[20:53]  * benji suspects lifeless has been replaced by a Russian imposter.
[20:53] <lifeless> in soviet russia, bugs close you
[20:54] <jcsackett> that sounds ominous.
[20:55] <benji> lol
[20:57] <lifeless> flacoste: on bug 419531 - are you aware that the same thing makes the legacy input box unusable in those situations ?
[20:57] <_mup_> Bug #419531: project name picker search / vocabulary is hard/impossible to use (too many results on exact searches) <disclosure> <project-picker> <vocabulary> <Launchpad itself:Triaged> < https://launchpad.net/bugs/419531 >
[21:09] <bac> jcsackett: you have time for a review?
[21:09] <flacoste> lifeless: it doesn't
[21:09] <lifeless> flacoste: its a different cause?
[21:09] <jcsackett> bac: sure.
[21:10] <bac> jcsackett: https://code.launchpad.net/~bac/launchpad/bug-750984/+merge/62543
[21:10] <sinzui> My team is work in that bug in the next two weeks, I have refrained from the niggling about its importance
[21:10] <lifeless> sinzui: sure
[21:10] <lifeless> and I'm ecstatic
[21:10] <flacoste> lifeless: ok, if you mean that the Choose button suffers from the same bug, yes, that's true, but the previous popup suffered from the same problem there
[21:10]  * sinzui think the search on summary and description leads to false matches
[21:10] <flacoste> lifeless: but you can still enter 'launchpad' in the input box like you used to and it will accept your input
[21:11] <lifeless> ah yes
[21:11] <lifeless> mmm
[21:12] <lifeless> this evaluation of regression is inconsistent with our bug triage docs & critical escalation rules. So I think we need to revisit them.
[21:14] <flacoste> how is it inconsistent
[21:14] <flacoste> ?
[21:15] <flacoste> and fwiw, deryck is working on clarifications to the bugtriage rule concerning UI issues
[21:15] <lifeless> thats great
[21:15] <lifeless> https://dev.launchpad.net/PolicyAndProcess/ZeroOOPSPolicy
[21:15] <lifeless> This mean that any user-visible error happening in production is a stop-the-line event and should be fixed ASAP
[21:15] <deryck> yeah, I'm really not try to niggle, as sinzui called. ;)  Just want to be clear about when something is critical or not.
[21:16] <lifeless> when we last spoke about, we decided js errors count as oopses
[21:16] <sinzui> lifeless: I believe there is a regression. The current code does not scale to the volume of projects we have now. The vocabulary uses searching-like behaviour which did work for a small set of project (with poor summaries and descriptions).
[21:16] <lifeless> and the motivation is solving problems users see promptly
[21:16] <lifeless> sinzui: I do too
[21:16] <lifeless> sinzui: but opinions differ
[21:17] <flacoste> i probably does need clarifications
[21:17] <sinzui> The useless number of results is because it matches "launchpad" or "ubuntu" in the project summary or description, but the user is thinking of the name or displayname
[21:17] <flacoste> but for the record
[21:17] <flacoste> i don't see any regression here
[21:17] <flacoste> nor any JS OOPS
[21:17] <lifeless> flacoste: I'm looking at the spirit not the legals :)
[21:18] <flacoste> i do too
[21:18] <flacoste> :-)
[21:18] <flacoste> if this was new work
[21:18] <flacoste> and would have been caught during acceptance testing, it would have warranted a High bug
[21:18] <lifeless> really?
[21:18] <lifeless> I would have marked something like this qa-bad and reverted.
[21:19] <lifeless> I am sure others in the team would have too - in fact we have done so in the last few months
[21:19] <flacoste> that doesn't match current practice
[21:19] <flacoste> in some case we have reverted
[21:20] <flacoste> in others we haven't
[21:20] <lifeless> then current practice is inconsistent :)
[21:20] <deryck> feature flags protect us, and prevent having to revert in some cases.
[21:20] <flacoste> i think it is consistent
[21:20] <flacoste> with applying common sense judgement
[21:20] <flacoste> about when the error is found
[21:20] <flacoste> and what's the impact of the error
[21:21] <flacoste> remember that exploratory testing happens after deployment
[21:21] <flacoste> so it's after the qa-bad step
[21:21] <lifeless> flacoste: qa happens before deployment
[21:21] <flacoste> i wouldn't thinkg the suitability for deployment check would have caught such a corner case
[21:22] <flacoste> i might have confused you
[21:22] <flacoste> by saying acceptance testing
[21:22] <lifeless> flacoste: its not such a corner case though
[21:22] <flacoste> when i really meant exploratory testing
[21:22] <lifeless> no, I knew you meant at the stakeholder-check phase
[21:22] <flacoste> yeah, that's after deployment
[21:22] <lifeless> which is nicely decoupled from deploys now
[21:22] <flacoste> again confusion with the terms
[21:23] <flacoste> i mean live on production (maybe behind a feature flag)
[21:23] <flacoste> but that's after qa-bad has any significance
[21:23] <lifeless> yes, I know, there is no confusion
[21:23] <lifeless> if its behind a feature flag it would not get qa-bad
[21:23] <lifeless> if someone noticed during qa
[21:23] <flacoste> of then we are saying the same thing then :-)
[21:23] <lifeless> and this is such a glaring issue, I'm reaonably sure someone would have noticed
[21:23] <lifeless> I usually test with launchpad itself on qastaging
[21:24] <poolie> hi lifeless
[21:24] <poolie> sorry about https://bugs.launchpad.net/bugs/786804
[21:24] <_mup_> Bug #786804: branch scanner rlimit failures cause the next branch to be incorrectly scanned and fail <oops> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/786804 >
[21:24] <flacoste> anyway, this is speculative at this stage
[21:24] <lifeless> flacoste: the regression angle i'm arguing is that the user story we had got broken
[21:24] <lifeless> flacoste: I know there are workarounds but the old story - including doing a choose based search - *no longer works*
[21:24] <flacoste> yeah, from my point of view, there is no additional breakage
[21:25] <lifeless> flacoste: and that is the *classic* definition of a regression.
[21:25] <flacoste> i'm arguing it didn't work before
[21:25] <flacoste> from the user point of view
[21:25] <flacoste> in both case, the work-around was the same
[21:25] <flacoste> enter the project name textually in the input box
[21:25] <lifeless> flacoste: what happened before?
[21:25] <flacoste> that hasn't regressed
[21:25] <flacoste> you just had too many results to sift through
[21:26] <flacoste> because we never ranked the result sanely
[21:26] <flacoste> launchpad wasn't in the first page of results
[21:26] <flacoste> might be hidden on the second or third page
[21:26] <flacoste> which is just as bad
[21:26] <flacoste> as saying: 'sorry dude, try again'
[21:26] <lifeless> flacoste: but its not equivalent - annoying vs impossible
[21:26] <flacoste> i bet there is a bug about that
[21:26] <flacoste> semantic
[21:28] <lifeless> poolie: thats fine; we traded 'the system dies in a fire' for 'bad jobs die quickly and oh we have missing code around handling such deaths'
[21:28] <lifeless> poolie: its a move forward overall
[21:28] <lifeless> deryck: feature flags are intensely useful
[21:28] <lifeless> flacoste: so, it returns 464 items
[21:28] <lifeless> flacoste: which is pretty useless
[21:29] <lifeless> flacoste: for launchpad itself
[21:29] <lifeless> searching for bazaar returns 320
[21:29] <lifeless> and AIUI the vocab wasn't changed
[21:29] <flacoste> yep
[21:30] <lifeless> so - I buy your analysis on this one
[21:32] <flacoste> lifeless: bug 255282
[21:32] <_mup_> Bug #255282: The string "launchpad" is hard to find in the Projects search <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/255282 >
[21:33] <lifeless> hahahaha
[21:33] <lifeless> sinzui: would it make your life hard if I dupe these ?
[21:33] <flacoste> it would appear on page 5!
[21:33] <deryck> we can all agree: if there's a dupe, it's not a regression! Consensus, yay! :-) :-)
[21:33] <flacoste> 2008-08-06: "I'd go so far as to say that the project search pop-up is rendered so useless by this almost-but-not-quite findable presentation that it perhaps ought to be removed until it can be fixed. I"
[21:34] <lifeless> deryck: heh. orthogonal I think :P
[21:34] <sinzui> lifeless: they are not the same :(
[21:34] <lifeless> sinzui: in that you can fix one without the other ? ok.
[21:34] <deryck> dang you sinzui  ;)
[21:35] <sinzui> lifeless: ProductSet find methods are not vocabulary lookup methods
[21:36] <lifeless> sinzui: huh, thats the vocab in use with the old UI, isn't it ?
[21:36] <sinzui> I noted to wgrant and jcsackett a few days ago that I was concern that PersonSet.findPerson() and the person vocabularies were both inconsistent and do not appear to know what use case they serve
[21:36] <flacoste> sinzui: bug 255282 is about the Choose widget which uses a vocabulary
[21:36] <_mup_> Bug #255282: The string "launchpad" is hard to find in the Projects search <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/255282 >
[21:36] <sinzui> This is true for several set vs vocabs and I would like dry code
[21:37] <flacoste> sinzui: i agree that it would be sane to use the model's find() method from the vocabulary
[21:37] <sinzui> flacoste: sorry I thought it was about /projects
[21:37] <lifeless> sinzui: I would like that too; I don't see that this is a case of that though. They describe the same widget as it used to be.
[21:37] <lifeless> I would like to dupe these on the old one and update its metadata.
[21:37] <lifeless> sinzui: will that cause you any difficulty?
[21:37] <flacoste> there is a slight variation
[21:38] <sinzui> They It is a dupe. I did fix the tags a moment ago though
[21:38] <flacoste> in that the new widget should allow exact match selection
[21:38] <flacoste> even if there are too many results for the search
[21:38] <lifeless> flacoste: thats about how we fix it
[21:38] <flacoste> yeah, agreed
[21:38] <lifeless> I think bugs should be separate if we're liable/reasonably going to fix one without the other
[21:39] <lifeless> but I don't think that applies here
[21:39] <sinzui> flacoste: the project vocan does not attempt to rank the quality of matches. people does, but I am given to understand the rank is dropped in a late step in the process :(
[21:41] <lifeless> ok
[21:42] <poolie> lifeless: glad to hear you think it's a step forward; on the whole so do i
[21:42] <lifeless> I've made the old one the master, moved the metadata across.
[21:42] <lifeless> EOF, next topic :)
[22:08] <lifeless> sinzui: please let me know if/when you'd like me to chat with you guys.
[22:16] <poolie> lifeless: should i feel the ulimit fallout is my obligation to address?
[22:20] <lifeless> poolie: no
[22:21] <lifeless> poolie: but I'd be delighted if you were to do so
[22:24] <poolie> i proposed some ideas
[22:24] <poolie> let me know what you think
[22:25] <poolie> i won't treat it as personally critical then, but i may try something
[22:54] <bigjools> can someone please look at this zope proxy problem I have and tell me where I am being completely stupid   http://pastebin.ubuntu.com/613493/
[23:08] <lifeless> do you have access to the attribute?
[23:08] <lifeless> if verifyObject runs as you, it might fail if you can't access the attribute
[23:15] <bigjools> lifeless: branch is here: https://code.launchpad.net/~julian-edwards/launchpad/packageupload-with-pcj
[23:15] <bigjools> ah cock
[23:16] <bigjools> it's an old-style zcml declaration with explicit properties instead of interfaces
[23:16] <lifeless> yup
[23:16] <bigjools> I hate soyuz
[23:16] <lifeless> only cause it hates you
[23:17] <bigjools> in soviet russia ...
[23:17] <bigjools> this is a good time to get the last ditch battery warning
[23:18] <bigjools> good night!
[23:18] <lifeless> nn
[23:21] <bigjools> lifeless: can I push without a repack happening?
[23:30] <thumper> email processing is fucked
[23:30] <thumper> I just checked the logs
[23:30] <thumper> not sure how long it has been fucked for though
[23:30] <thumper> at least an hour
[23:30] <lifeless> details!
[23:30] <thumper> 2011-05-26 22:18:23 ERROR   An exception was raised inside the handler:
[23:30] <thumper> http://launchpadlibrarian.net/72491135/1052aa70-87e6-11e0-a1bd-001e0bc3957e.txt
[23:30] <thumper>  -> http://launchpadlibrarian.net/72491136/9DXUl51Txcr83QLvOBe5YOGwyvJ.txt (Msg <1306439950.10927.2.camel@nbjplevy> size 12930186 exceeds limit 10485760)
[23:30] <thumper> every 30 seconds
[23:31] <thumper> failing on the same incoming email message
[23:43] <mwhudson> whoops
[23:44] <wgrant> sinzui: The pickers and vocabs are pretty bad, yeah :(