[00:29] <wgrant> lifeless: Hi
[00:29] <lifeless> hi
[00:29] <wgrant> lifeless: Can you try to outsmart the planner for me? :)
[00:29] <lifeless> there is no try
[00:29] <lifeless> only do, or do not
[00:31] <wgrant> lifeless: http://paste.ubuntu.com/903111/
[00:31] <wgrant> With seqscans forbidden it takes 950ms, but when permitted it applies them liberally and takes 3500ms.
[00:32] <wgrant> I can get it down to 1100ms by employing the perplex-a-planner strategy of pushing everything out into CTEs.
[00:33] <lifeless> qastaging ok for this?
[00:33] <wgrant> Ja
[00:33] <wgrant> Ah
[00:33] <lifeless> grah unity
[00:34] <wgrant> You'll need different AccessPolicy IDs.
[00:34] <lifeless> I *so* hate the 'raise all windows of an app' behaviour
[00:34] <wgrant> SELECT id FROM accesspolicy WHERE distribution=1;
[00:34] <lifeless> it breaks me every time I alt-tab
[00:35] <lifeless> so much more fiddly than metacity
[00:35] <lifeless> wgrant: two rows
[00:35] <lifeless> 65 type 4
[00:35] <wgrant> Those are the IDs that the query needs.
[00:36] <lifeless> 66 type 3
[00:36] <lifeless>  Total runtime: 1094.256 ms
[00:36] <lifeless> (17 rows)
[00:36] <lifeless> default behaviour
[00:36] <lifeless> how fast do you need this?
[00:37] <wgrant> orly
[00:37] <wgrant> Um
[00:37] <wgrant> As fast as possible :)
[00:37] <lifeless> http://paste.ubuntu.com/903115/
[00:38] <lifeless> thats with grantees AS (...
[00:38] <wgrant> http://paste.ubuntu.com/903116/ is the perplex-a-planner strategy.
[00:38] <wgrant> How does that perform?
[00:38] <lifeless> 730ms hot (the first one I tried, looking at your new one now)
[00:38] <wgrant> Hm, not bad.
[00:38] <wgrant> That's almost acceptable, in fact.
[00:39] <lifeless> 719ms for the perplex
[00:39] <lifeless> 711ms hot
[00:39] <wgrant> That's more sensible.
[00:39] <wgrant> Because it's saving a lot of TP lookups.
[00:39] <lifeless> 770ms
[00:39] <lifeless> some variation
[00:39] <wgrant> Can has explain analyze?
[00:39] <lifeless> http://paste.ubuntu.com/903118/
[00:40] <wgrant> And one of the hot original query?
[00:40] <lifeless> http://paste.ubuntu.com/903120/
[00:40] <wgrant> Thanks,.
[00:42] <lifeless> this is showing the expanded out list of people right? The crazy thing.
[00:43]  * lifeless thinks we're failing to make it usable
[00:44] <wgrant> lifeless: Yeah, the filterable expanded audit view.
[00:44] <lifeless> btw
[00:44] <lifeless> person_sort_key -> 24 seconds
[00:45] <wgrant> Er, really?
[00:45] <wgrant> It wasn't that bad last I checked.
[00:45] <lifeless> yup
[00:45] <wgrant> 2500ms here
[00:46] <wgrant> Still far worse than expected.
[00:46] <wgrant> But not 24s...
[00:46] <lifeless> 1440ms for the confuddle-the-planner query
[00:46] <lifeless> http://paste.ubuntu.com/903125/
[00:47] <lifeless> so I really think we shouldn't do this at all
[00:47] <lifeless> Who do I need to speak to to steer this
[00:47] <lifeless> Curtis?
[00:47] <wgrant> He's probably the first point of contact.
[00:48] <lifeless> pagination 180K rows of anything is pointless.
[00:48] <lifeless> There is /no/ way its usable.
[00:48] <wgrant> Oh yes.
[00:48] <lifeless> sinzui: ^ hi. I'd like to arrange time to talk about this.
[00:48] <wgrant> But for sensible projects it should be fine.
[00:48] <wgrant> There might be a hundred in total.
[00:48]  * StevenK tries to find an API method that takes an enum as a parameter.
[00:48] <wgrant> StevenK: searchTasks
[00:48] <lifeless> StevenK: searchTasks
[00:48] <wgrant> StevenK: addMember
[00:49] <wgrant> lifeless: THe auditing view is only meant to be useful for sensible projects.
[00:49] <wgrant> lifeless: And potentially for auditing All sharing in Ubuntu.
[00:49] <wgrant> Which will be much smaller sets.
[00:49] <wgrant> However, I needed to find out whether it would vaguely work on the full Ubuntu set.
[00:50] <wgrant> Or if we'd have to take evasive action.
[00:51] <poolie> lifeless, your comment on 956655
[00:51] <poolie> > It configures it to talk to the *host side address of the libvirt
[00:51] <poolie> bridge*.
[00:51] <poolie> what's the result of that?
[00:51] <poolie> isn't it that the packets are passed through to the guest?
[00:51] <poolie> o/ wgrant
[00:51] <wgrant> Morning poolie.
[00:51] <lifeless> poolie: no, libvirt runs a dnsmasq there
[00:51] <wgrant> poolie: No, the host has an interface on the bridge.
[00:52] <lifeless> poolie: as part of it running dhcp etc for the containers/vms
[00:52] <poolie> ok
[00:52] <lifeless> (well, I say libvirt, I'm not 100% sure *what* is responsible for starting that dnsmasq up, but thats orthogonal to it existing :))
[00:52] <poolie> so i think the echo is actually between the host's general dnsmasq and this one
[00:53] <poolie> so i was inaccurate to say 'in the guest'
[00:59] <wgrant> lifeless: (also, there's only 20000, not 100000 :P)
[01:00] <lifeless> wgrant: oh, read the wrong row out? Still. Its more than 200.
[01:01] <wgrant> lifeless: Right. There's about 19000 explicit grants, expanding to 20000 when team members are included.
[01:01] <StevenK> So paginating more than 200 items is wrong?
[01:01] <wgrant> Er
[01:01] <wgrant> s/explicit grants/distinct people and teams with explicit grants/
[01:01] <wgrant> lifeless: http://people.canonical.com/~curtis/audit/ are mockups of the UI
[01:02] <lifeless> StevenK: for usability, yes.
[01:03] <lifeless> StevenK: some folk say more than 30 or 40
[01:04] <StevenK> lifeless: Reading it that, that makes our critical bug list, and Ubuntu's bug listing is unusable.
[01:04] <wgrant> Nobody would argue that they're usable.
[01:04] <lifeless> StevenK: they are
[01:04] <lifeless> StevenK: we do two things with them commonly: we data mine to extract patterns that are much shorter - human scale
[01:04] <lifeless> StevenK: and we provide a search facility to let folk find things that interest them within the big pile
[01:06] <lifeless> StevenK: how would you answer the question 'is ~somebodyinlotsofteams in ~ubuntu-members' ?
[01:06] <lifeless> StevenK: and how would you *like* to be able to answer that?
[01:06] <StevenK> Hmmmm.
[01:07] <StevenK> lifeless: So to be fair, I was trying to troll you. Clearly, I failed epically. :-)
[01:08] <lifeless> the key to a good troll is to say something thats totally outrageous in a way that sounds plausible, or something thats *nearly* plausible but really actually silly.
[01:08] <lifeless> Speaking the truth, not a troll!
[01:12] <StevenK> wallyworld_: So I think I've made bugs-remove-old-privacy safe enough to land whenever, but I'd like a second set of eyes.
[01:13] <wallyworld_> StevenK: sure, can you remind me of the link?
[01:13] <StevenK> It flips CreateBugParams() to using information_type and keying private and security_related off of it.
[01:13] <StevenK> wallyworld_: It will be a few minutes, I need to push and wait for the diff.
[01:13] <wallyworld_> ok, np
[01:22] <StevenK> wallyworld_: https://code.launchpad.net/~stevenk/launchpad/bugs-remove-old-privacy/+merge/98974 -- diff updated, and I've rewritten parts of the description, so glance at that too.
[01:22]  * wallyworld_ looks
[01:23] <StevenK> wallyworld_: But you were happy with it before, so I'm okay with it if you want to 1) just read the diff for r14994, and 2) read the big diff to see how those changes fit into the big picture.
[01:24] <wallyworld_> sure
[01:39] <wallyworld_> StevenK: why are we adding the individual private/security attributes back? waiting for db patches to land?
[01:40] <StevenK> wallyworld_: So it's safe to land no matter the state of the DB patches, and so I can base the UI branch off that work.
[01:43] <wallyworld_> StevenK: and because we have allow multi-pillar private bugs for everyone via the feature flag, that extra exception won't matter
[01:44] <wgrant> StevenK: Why do you unprivate the bug in lib/lp/bugs/doc/bug.txt?
[01:45] <StevenK> wgrant: For the reason I gave in the description -- without the feature flag turned on, we will now always complain in transistionToInformationType()
[01:47] <wallyworld_> StevenK: will the extra complaining be temporary?
[01:47] <wgrant> StevenK: I don't see an explanation of that.
[01:47] <StevenK> wgrant: "This slightly changes the behavior of the function, since it will now always complain about multi-pillar private bugs whereas it used to only care if you were flipping the privacy flag."
[01:48] <wgrant> Ah.
[01:49] <StevenK> wallyworld_: That is the 64-million dollar question, isn't it?
[01:50] <StevenK> wallyworld_: I'm not sure about the timeline of multi-pillar private bugs complaining.
[01:50] <wallyworld_> StevenK: so once all the legacy stuff is removed, we only want to complain if the info type transitions to embargoed sucurity or user data or proprietary?
[01:51] <wallyworld_> or did we decide to allow such things now and remove the fflag and check entirely?
[01:51] <StevenK> There was talk of a footgun.
[01:51] <wallyworld_> so why can't we fix the errouneous complaining in the current branch?
[01:52] <wgrant> The multi-pillar restriction only applies to PROPRIETARY
[01:52] <wgrant> But the code has not yet been fixed.
[01:52] <wallyworld_> ok. i was thinking it applied to user data etc also
[01:52] <StevenK> I can do that in this branch if you like, but we haven't defined what the heck PROPRIETARY means for bugs.
[01:52] <wgrant> userdata potentially.
[01:53] <wgrant> But applying it to embargoedsecurity was vetoed.
[01:53] <wgrant> It needs to be a separate branch.
[01:53] <wallyworld_> let's land this then since it's moot given the current sdtate of the fflag
[01:53] <StevenK> So you two are happy with it as it stands right now, and we can fiddle it later?
[01:54] <wallyworld_> i think so
[01:54] <wgrant> I'm only half done, but happyish so far.
[01:54] <StevenK> wgrant: Anything I can do to flip you from happyish to happy?
[01:55] <wgrant> StevenK: lib/lp/bugs/mail/commands.py is confusing and buggy
[01:55] <wgrant> And it's using 'is' instead of '=='
[01:56] <wgrant> What happens if I set a bug private when it's UNEMBARGOEDSECURITY?
[01:56] <wgrant> Seems like it will become PUBLIC
[01:56] <wgrant> Also if I try to make  USERDATA bug private, it will become public.
[01:56] <StevenK> wgrant: I plan on reworking that in a later branch when I add a information_type flag.
[01:56] <wgrant> Yes, but this is fail-open buggy.
[01:56] <wgrant> cannot land.
[01:57] <StevenK> wgrant: So currently you can't have UNEMBARGOEDSECURITY in the mail handler.
[01:57] <StevenK> So we're only tracking three states.
[01:58] <wgrant> StevenK: Ensure that.
[01:58] <wgrant> s/else/elif blah/
[01:58] <wgrant> And else: raise AssertionError("shit is broken")
[01:59] <StevenK> wgrant: Yeah, I was reading over the diff and shaking my head a little at what I wrote in mail commands.
[01:59] <wgrant> Setting it to public because it was proprietary sounds bad.
[01:59] <wgrant> 393	- # BugSet.createBug() requires new security bugs to be private.
[01:59] <wgrant> 394	- context.private = True
[01:59] <wgrant> 395	+ context.information_type = InformationType.EMBARGOEDSECURITY
[01:59] <wgrant> 396	+ else:
[01:59] <wgrant> 397	+ context.information_type = InformationType.PUBLIC
[01:59] <wgrant> Is also a bit odd
[01:59] <wgrant> I suspect it defaults to PUBLIC
[01:59] <wgrant> So it might be nice to avoid explicitly setting it.
[02:00] <wgrant> For the same reason.
[02:00] <StevenK> wgrant: 'security no' -> PUBLIC, unless private is true
[02:01] <wgrant> Sure, but the old code didn't do anything in that case.
[02:01] <wgrant> The old code purely overrode to security_related=True if security=True
[02:02] <wgrant> s/security_related/private/
[02:02] <wgrant> 621+ if self.information_type is information_type:
[02:02] <wgrant> Should probably be ==, again
[02:05] <wgrant> You can't spell 'privileged'
[02:05] <wgrant> (line 741)
[02:05] <StevenK> Which line number?
[02:05] <lifeless> 741
[02:05] <wgrant> A tonne more 'is'
[02:06] <wgrant> 803+ bug_privacy_filter = 'AND Bug.information_type IN (1, 2)'
[02:06] <wgrant> That shouldn't be literal.
[02:07] <wgrant> And in bugtasksearch.py
[02:08] <wgrant> 1134	where=And(
[02:08] <wgrant> 1135	- Bug._private == True,
[02:08] <wgrant> 1136	+ Bug.information_type in PRIVATE_INFORMATION_TYPES,
[02:08] <wgrant> Always True
[02:08] <wgrant> 1144	+ where=And(Bug.information_type in PRIVATE_INFORMATION_TYPES,
[02:08] <wgrant> 1145	+ BugTask.assignee == self.id)),
[02:08] <wgrant> Likewise
[02:08] <wgrant> 1166	+ SELECT Bug.id FROM Bug WHERE Bug.information_type IN
[02:08] <wgrant> 1167	+ (1, 2)
[02:08] <wgrant> More literals where the enum should be.
[02:09] <wgrant> wtf is there a createBug in lp.systemhomes
[02:09] <wgrant> Otherwise looks good.
[02:09] <StevenK> I have no re systemhomes
[02:09] <StevenK> no idea
[02:09] <StevenK> wgrant: I can't use Bug.information_type in PRIVATE_INFORMATION_TYPES in storm?
[02:10] <wgrant> No
[02:10] <wgrant> You might recall that I nuked lots of the Ubuntu archive like that once.
[02:10] <StevenK> Haha
[02:12] <StevenK> wgrant: What's the right pattern, then?
[02:12] <wgrant> .is_in(blah), probably
[02:13] <StevenK> Right
[02:33] <lifeless> cjwatson: how did you go w/LoC?
[02:45] <cjwatson> lifeless: Clawed it down to +56/-57.
[02:45] <cjwatson> (I refactored the tests a bit.)
[02:45] <lifeless> cool
[02:45] <cjwatson> Also submitted a +0/-531 branch to store up some credit ;-)
[02:48] <lifeless> hah :)
[02:52] <cjwatson> (Is there a graph somewhere of the Launchpad line count over time?)
[02:57] <lifeless> flacoste has muttered about making one
[02:57] <lifeless> for every project we have
[02:58] <spm> spads did a very nice bubbles of code/person over time viewy thingy of our puppet branch. rather amusing to see. I don't recall the proper name for those offhand; but he may have some advice to offer there?
[02:59] <cjwatson> code_swarm?
[03:00] <cjwatson> http://code.google.com/p/codeswarm/
[03:19] <wgrant> cjwatson, lifeless: https://www.ohloh.net/p/launchpad
[03:21] <wallyworld_> wgrant: what's the verdict on the sharing team participation query?
[03:23] <wgrant> wallyworld_: http://paste.ubuntu.com/903111/ works well on qastaging
[03:23] <cjwatson> wgrant: ah, cute
[03:24] <wallyworld_> wgrant: thanks, will use that as a starting point
[03:24] <lifeless> wgrant: as long as you don't use person_sort_key
[03:24] <lifeless> wgrant: where it goes to 24 seconds
[03:24] <wgrant> lifeless: I still don't believe that.
[03:24] <wgrant> But we can't anyway due to SRF.
[03:24] <wallyworld_> lifeless: at the moment, we can't use person_osrt_key anyway
[03:24] <lifeless> check the explain analyze I gave you :)
[03:26] <wgrant> what the postgres
[03:27] <wgrant> How could it think that was a good idea?
[03:27] <wgrant> Oh
[03:27] <wgrant> The sort index
[03:27] <wgrant> It uses the bloody sort index.
[03:27]  * wgrant drop index and retries.
[03:28] <wgrant> Magical, 1s.
[03:28] <wgrant> Postgres, you are a moron.
[03:30] <StevenK> wgrant: Do you want to recheck that MP? I think I've addressed all of your concerns.
[03:30] <wgrant> StevenK: In a few, once I've lunched.
[03:30] <StevenK> I'll start putting together a UI branch
[03:30] <StevenK> Since I'm mostly happy with that one.
[03:39] <lifeless> wgrant: so, I'll leave that happy thought with you
[03:40] <wgrant> lifeless: You're so kind :)
[03:40] <wgrant> Its estimates aren't even that far off :(
[03:42] <lifeless> wgrant: I aim to please.
[03:43] <lifeless> (time to do my allhands stuff. \i/.
[03:43] <wgrant> That reminds me
[03:43] <wgrant> I have more of that wondrous task to do
[03:44] <lifeless> 'am I wonderful? Yes I am!'
[04:13] <StevenK> cjwatson: If you're still around, I've approved all three of your MPs, do you want to toss them at ec2?
[04:13] <StevenK> cjwatson: Or shall I?
[04:53] <StevenK> Bah, I hate how I can figure out what I want the portlet to say, but don't know enough about the privacy portlet or TAL to express it :-(
[05:01] <wgrant> StevenK: Sorry, looking at your MP again now.
[05:01] <StevenK> Hah.
[05:01] <wgrant> StevenK: I'd do sqlvalues(PUBLIC_INFORMATION_TYPES)
[05:01] <wgrant> Rather than spelling out '(%s, %s)
[05:02] <wgrant> ' % (InformationType.blah.value, blah, blah)
[05:02] <StevenK> %s' % sqlvalues() is it, I guess?
[05:02] <wgrant> Should work
[05:02] <wgrant> Possibly needs manual parens, but I don't quite remember.
[05:02] <wgrant> I use native Storm parameterisation where possible now, but it's a bit harder here.
[05:03] <wgrant> lifeless: Can I set the 5s timeout on Product:+sharing and Distribution:+sharing now?
[05:03] <StevenK> wgrant: I didn't change the tests, so they're still looking for "IN (1, 2)" in the text
[05:06] <wgrant> StevenK: The bug search query changes should be feature-flagged.
[05:06] <wgrant> StevenK: They have the potential to completely destroy bug search performance.
[05:06] <StevenK> Haha, PUBLIC_INFORMATION_TYPES doesn't exist.
[05:06] <wgrant> Correct.
[05:06] <wgrant> But it can easily be brought into existence.
[05:08] <StevenK> wgrant: I can revert the bug search query changes and we fix it with BugTaskFlat?
[05:10] <wgrant> StevenK: That might be best.
[05:10] <wgrant> It should be fairly safe.
[05:10] <wgrant> But you never know, and there's hundreds of cases.
[05:11] <StevenK> wgrant: I figured that I didn't want to play with bringing up a feature flag and playing with that function more when you're going to rip it to pieces in a week or two.
[05:24] <StevenK> Hmmmm, it's taking a very very long time to save MP comments today.
[05:25] <StevenK> wgrant: Perhaps something in the NDT we did today is to blame?
[05:26] <StevenK> wallyworld_: Your two MPs are approved
[05:27] <StevenK> wgrant: Do you have any other comments?
[05:28] <wgrant> StevenK: Commenting is fast for me.
[05:29] <wgrant> StevenK: commands.py is still unintelligible.
[05:29] <StevenK> Perhaps it was the nine MP pages I had open, but approving one of wallyworld_'s MPs took 200 seconds.
[05:29] <wgrant> And you can't spell 'Unknown'
[05:29] <wgrant> That would be the nine MP pages, yes.
[05:29] <wgrant> Longpoll connection exhaustion.
[05:30] <StevenK> But approval doesn't require longpoll?
[05:30] <wgrant> The limit is a general browser per-domain connection limit.
[05:30] <StevenK> wgrant: What about commands.py is still unintelligible?
[05:35] <wgrant> StevenK: What's wrong with:
[05:36] <wgrant> if information_type == UNEMBARGOEDSECURITY: information_type = EMBARGOEDSECURITY
[05:36] <wgrant> elif private and information_type == PUBLIC: information_type = USERDATA
[05:36] <wgrant> else: wtf
[05:36] <wgrant> (ideally the first branch wouldn't be required, but I suspect it might be)
[05:38] <StevenK> wgrant: security_related just sets to EMBARGOEDSECURITY if it's set. But I don't want to just set it to USERDATA if the next command is private yes
[05:39] <StevenK> Hmmm, the current tests trip that assert.
[05:39] <wgrant> Ah, so this is only for creation.
[05:39] <StevenK> Yes.
[05:40] <StevenK> wgrant: If the bug exists, the mail handlers just call set{Private,SecurityRelated} and job done. If the context is CreateBugParams, it needs to be kept in a sane state since it's used to file the bug.
[05:42] <StevenK> Ah ha.
[05:42] <wgrant> StevenK: So, if it's PUBLIC or USERDATA, it goes to PUBLIC or USERDATA depending on value. If it's UNEMBARGEODSECURITY or EMBARGOEDSECURITY it goes to EMBARGOEDSECURITY
[05:42] <wgrant> If it's proprietary, it crashes.
[05:42] <StevenK> At the moment, it doesn't do that.
[05:43] <wgrant> This is the behaviour that the command has in the new world.
[05:43] <wgrant> It may not be how it's currently implemented.
[05:43] <StevenK> What's going on is the test creates a params with EMBARGOEDSECURITY and then executes private no, which asserts
[05:43] <wgrant> But that's how it is.
[05:44] <wgrant> Actually, I guess on creation UNEMBARGOEDSECURITY should crash now.
[05:44] <StevenK> I think that assert lives on.
[05:44] <StevenK> Sadly.
[05:45] <StevenK> wgrant: This is why I force to EMBARGOEDSECURITY with security_related, it's what we're currently expecting.
[05:46] <wgrant> It should be impossible, but indeed, I guess that makes sense.
[05:48] <wgrant> So, case information_type of (PUBLIC, USERDATA) -> {False: PUBLIC, True: USERDATA}[private]; (UNEMBARGOEDSECURITY, EMBARGOEDSECURITY) -> EMBARGOEDSECURITY; otherwise -> error
[06:02] <lifeless> wgrant: please do
[06:03] <wgrant> lifeless: Thankyou sir.
[06:08] <wallyworld_> StevenK: thank you
[07:44] <danhg> Morning
[07:50] <adeuring> good morning
[07:55] <lifeless> stub: hey
[07:55] <lifeless> stub: reminder: hr stuff is due today
[07:56] <stub> lifeless: I'm a few days ahead of you. All tasks done (although I didn't get requested for peer reviews? Maybe because I don't have any peers with the new structure, or is that next cycle?)
[07:57] <lifeless> stub: oh excellent
[07:57] <lifeless> stub: the system doesn't make it terribly clear what reports have/haven't done.
[07:57] <lifeless> stub: thanks!
[07:57] <lifeless> stub: peer reviews are done by doing 'select peer' in the UI
[07:57] <lifeless> stub: if you haven't been asked to do any, noone has asked you is all.
[07:58] <lifeless> stub: feel free to reach out and ask for reviews from e.g. folk you've helped, whatever team they are in.
[07:58] <lifeless> stub: 2 or 3 is probably a good number
[08:01] <lifeless> wgrant: so what did you think of the checkmarkable thing ?
[08:02] <lifeless> wgrant: if we were for instance, to ditch some of our policy and process wiki pages for such checklists, would it be good, or bad, or meh?
[08:02] <wgrant> lifeless: It looks like a good idea.
[08:02] <wgrant> lifeless: Seems pretty incomplete and somewhat awkward at present.
[08:02] <wgrant> But promising.
[08:05] <lifeless> I'll show flacoste and statik and get their thoughts
[08:17] <cjwatson> StevenK: I don't believe I have access, or at least if I do I don't have it set up; so please do lob them at EC2, thanks.
[08:30] <StevenK> cjwatson: You could probably ask for PQM access -- but in either case, I'll land remove-archive-override-check directly and throw the other two at ec2.
[08:32] <gmb> danhg, Morning. Just wanted to update you on the blog post I've written about Yellow + Juju: I'm redrafting it because it repeated large swathes of what Benji said; should have it to you by EOD though.
[08:32] <gmb> (Completely forgot to send it to you on Monday; apologies)
[08:39] <cjwatson> StevenK: yeah, Francis suggested that at one point.  Maybe I'll think about it around my next LP hacking spree :)
[08:39] <czajkowski> aloha
[08:40]  * StevenK kicks pqm-submit
[08:40] <StevenK> Getting very close to just drafting a signed message
[08:41] <danhg> Hey gmb, thanks so much for that - will ping you now...
[08:54] <StevenK> cjwatson: Victory, finally.
[08:57] <cjwatson> Cool.
[09:00] <jtv> huwshimi: are you eod?
[09:00] <huwshimi> jtv: Just on a call and then I'll be free
[09:00] <jtv> Great, thanks
[09:25] <huwshimi> jtv: I'm back
[09:25] <jtv> Hi
[09:26] <jtv> I'm trying to get a handle on the workings of nodes_chart.js.
[09:26] <jtv> Whether I get to fix the bug or not, I though adding some nodes would be useful.
[09:26] <huwshimi> nodes or notes?
[09:26] <jtv> notes, sorry!
[09:26] <huwshimi> :)
[09:26] <jtv> My fingers form habits.
[09:26] <huwshimi> yeah...
[09:26] <huwshimi> jtv: I need to go back and refactor a bunch of that js
[09:26] <jtv> The raised middle finger earlier was accidental as well.
[09:27] <huwshimi> haha
[09:27] <jtv> I figure I could do some of that.
[09:27] <jtv> Oh, you didn't notice the middle finger?  It was, er, hypothetical.
[09:27] <jtv> Yeah, that's the ticket.
[09:27] <huwshimi> jtv: You're more than welcome to, but I'm happy to fix up what I started :)
[09:28] <jtv> Okay, if you're motivated to do it, then I can leave it at this.
[09:28] <jtv> With gratitude, even!
[09:28] <huwshimi> jtv: There are already a bunch of notes on the MP from Raphael
[09:28] <jtv> If you're not, well, I'm here to help.
[09:28] <huwshimi> jtv: Yeah, really it's all good. I understand the code pretty well
[09:28] <huwshimi> and I know you guys are busy!
[09:28] <jtv> Then my advice is: write it all down before you forget!
[09:29] <huwshimi> It's on my list of things for early next week
[09:29] <jtv> OK, perfect.  Then I'll just drop this whole issue like a hot potato!
[09:29] <jtv> Thanks.
[09:30] <huwshimi> jtv: Great, no problems :)
[09:30]  * jtv goes browse car pictures
[09:30] <huwshimi> jtv: OK, I'm off too, catch you later
[09:30] <cjwatson> StevenK: remove-archive-override-check didn't need a [no-qa] or something?
[09:30] <jtv> nn!
[09:30] <cjwatson> Or have the rules changed?
[09:31] <cjwatson> StevenK: oh, never mind, I see the commit message that actually landed in devel had [no-qa].
[13:44] <deryck> rick_h, hey.  also.... it seems you took an action from the last TL call.  I'm assuming you didn't look at that yet?
[13:45] <abentley> adeuring: In your regular expressions, ".*?" looks equivalent to ".*" to me.  Am I missing something?
[13:46] <adeuring> abentley: it's just the non-greedy variant. SHould be slightly faster
[13:47] <adeuring> I simply prefer this one ;)
[13:47] <rick_h> deryck: ah right. let me pull that back up
[13:47] <deryck> rick_h, don't loose any time over it today, since we've lost a bit to convoy lately.... but let's chat about it in our call later.
[13:47] <abentley> adeuring: Oh, I didn't realize that was a thing.  I thought you were using ? to mean optional.
[13:48] <rick_h> deryck: ok, trying to find the email on that. Honestly forgot all about that after I handed over notes
[13:49] <deryck> rick_h, yeah, no worries.  it was new for you.  let's just chat about how to investigate those sorts of things, and then you can finish it this week, after you've gotten further on the email bug.
[13:50] <adeuring> abentley: >>> re.search('(.*?)a', '123aabab').groups()
[13:50] <adeuring> ('123',)
[13:50] <adeuring> >>> re.search('(.*)a', '123aabab').groups()
[13:50] <adeuring> ('123aab',)
[13:50] <rick_h> deryck: ah I remember now. Yea, I got the bug number from StevenK. Let me find that bug. That's all I did with it was to follow up and find the bug.
[13:52] <rick_h> deryck: https://bugs.launchpad.net/launchpad/+bug/724750 for your notes
[13:52] <_mup_> Bug #724750: launchpad redirects pack files to https://launchpad.net (while repacking?) <Launchpad itself:Triaged> < https://launchpad.net/bugs/724750 >
[13:52] <rick_h> ty giant irc logs
[13:53] <deryck> rick_h, ok, we'll look together during our call.  Thanks!
[13:54] <abentley> adeuring: r=me.
[13:54] <adeuring> abentley: thanks!
[14:31] <rick_h> is there a way in tests to specify a single test? using nosetests for instance I can do a --with-id xx to run a single test
[14:49] <deryck> rick_h, couple ways....
[14:49] <deryck> rick_h, either use the -t option and specify a very explicity regex, or drop the -t and full dotted path to test, i.e. lp.bugs.tests.test_xxx
[14:50] <rick_h> deryck: right, so that's to the file, but not a test within the file
[14:50] <rick_h> deryck: I think for now I just moved my test to its own file to speed things up
[14:50] <rick_h> and will clean up once things are going ok, just curious if there was a way to get at a single test within the file
[14:51] <deryck> rick_h, so this kind of thing works for me:
[14:51] <deryck> ./bin/test -cvvt lp.bugs.browser.tests.test_bugtask.TestDistributionBugs.test_mustache_cache_none_for_feeds
[14:51] <rick_h> deryck: ah, gotcha awesome
[14:52] <deryck> rick_h, you can also just pass the final test name to -t, but if there's more than one test with that name it will run them all.
[14:53] <rick_h> ok, I thought it was only file based, awesome to know it's more than that
[15:31] <deryck> jcsackett, hey man.  are you able to qa bug 933797 today?
[15:31] <_mup_> Bug #933797: Cannot see the Some things that are shared with a user <disclosure> <qa-needstesting> <ui> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/933797 >
[15:46] <benji> rick_h: anyother little test runner tidbit: you can use -m to speed up test runs; it specifies the module(s) that should be scanned for tests, so if you're running lp.foo.bar.TestBaz.test_baz, you can add "-m lp.foo.bar" to the command line to tell the test runner to only look there for tests
[15:46] <rick_h> benji: ooh, ty
[15:46] <benji> on my box it makes test runs about 6 or 7 seconds faster
[16:11] <abentley> rick_h: You can also omit the -m, but this gives substring matches rather than regular expression matches.
[16:53] <jcsackett> deryck: would've replied earlier but didn't see the highlight.
[16:53] <jcsackett> i'm about to start qa-ing it right now.
[17:05] <barry> we have a user who is changing bug statuses against our will.  is there anything we can do to prevent this?
[17:11] <barry> flacoste or sinzui ^^ perhaps?
[17:12] <sinzui> barry, czajkowski, can contact the user and ask him to desist. She might choose to suspend the user first so that he understands we mean it
[17:13] <sinzui> oh, but I think she EODed
[17:13] <barry> sinzui: cool, i've done the former.  if he continues i'll ask czajkowski to do the latter
[17:14] <barry> thanks!
[17:14] <sinzui> barry, report the issue as a question at https://answers.launchpad.net/launchpad and provide the user's Lp Id and an example bug id
[17:14] <sinzui> I will start action
[17:17] <deryck> jcsackett, cool, thanks man!
[17:18] <barry> sinzui: https://answers.launchpad.net/launchpad/+question/191955
[17:27] <czajkowski> sinzui: wahts up sorry was just on bus home
[17:29] <sinzui> czajkowski, I just sent a warning email to the user mentioned in barry's question
[17:30] <sinzui> Looking at the user's Lp profile, I think he is confused about what Lp is
[17:30] <czajkowski> sinzui: just ack the lp
[17:30] <czajkowski> have seen that person at it already before
[17:32] <barry> thanks guys!
[17:33] <czajkowski> barry: np
[17:56] <lifeless> sinzui: hola
[17:56] <sinzui> hi lifeless
[17:57] <lifeless> do you have time for a quick skype/hangout? I want to talk about a bit of the sharing UI & usability
[17:57] <lifeless> you may have seen your name in scrollback :)
[17:59] <lifeless> sinzui: ^
[18:00] <sinzui> yes. I never promised that feature to Ubuntu. only oem wants it because they will murder us if we do not allow them to continue auditing their projects
[18:00] <lifeless> flacoste: I've sent you an invite to a shared-checklist/process thing, would like to know what you think about it
[18:00] <lifeless> sinzui: so, skype or hangout, or $other/
[18:00] <sinzui> hangout
[18:00] <sinzui> I am ready
[18:01] <lifeless> invite sent
[18:03] <sinzui> I got the invite right away, but the button will not show.
[18:03]  * sinzui continues to kick google
[18:03] <lifeless> https://plus.google.com/hangouts/a3baf4b8edd991e0d6fdd61b85d31012c81a2a69?lm1=1332957654772&authuser=0&hl=en#
[18:04] <sinzui> interesting, google will show me notifications when it is not even certain I am logged in to interact with them
[18:05] <lifeless> different service endpoints I suspect
[18:40] <deryck> abentley, hi there.  I've got one for review if you are available.
[18:40] <abentley> deryck: sure thing.
[18:40] <deryck> abentley, thanks!  https://code.launchpad.net/~deryck/launchpad/person-latest-bugs-listings-921366/+merge/99800
[18:45] <abentley> deryck: I think you could avoid re-indenting all that code by doing "if getFeatureFlag('bugs.dynamic_bug_listings.enabled') and not FeedsLayer.providedBy(self.request)"
[18:46] <deryck> abentley, I thought the same, but I thought it was more obvious what the code would like look once the feature flag check goes away.  I'm not picky though.  I can change back to that if you think it's better.
[18:48] <abentley> deryck: I guess I thought it was better because it makes it obvious that none of the contained code has changed, but it doesn't matter now.
[18:49] <deryck> abentley, yeah, it's a fair point.
[18:50] <abentley> deryck: Did you consider making getFeedViewCache a function?  That way you don't need to create another class.
[18:52] <deryck> abentley, no, I didn't actually.  I'm okay with making it a function.
[18:52] <abentley> deryck: Cool.
[18:54] <abentley> deryck: I could swear we had a general-case version of _createView, but I'm having trouble remembering exactly where it is.
[18:55] <deryck> abentley, yeah, I couldn't find it either.  Code feeds had basically what I added to bug feeds, so was following the pattern there.
[18:59] <abentley> deryck: I think it is lp.testing.views.create_view / create_initialized_view
[19:00] <deryck> abentley, do you mean to replace what I did in the test or what I did in the feed classes?
[19:01] <abentley> deryck: Oh, I see.  I thought that was test code.
[19:02] <deryck> abentley, ah, ok.  no, it's just meant to make the feed classes easier to test.
[19:04] <abentley> deryck: Okay, never mind, then.
[19:05] <abentley> deryck: r=me
[19:06] <deryck> abentley, awesome, thanks.
[19:06] <abentley> deryck: np, it
[19:06] <abentley> 's what I'm here for.
[20:19] <lifeless> -> my monthly allergy shot, back in a while (wil mis the TL meeting)
[20:59] <salgado> hmm. the work items field has vanished
[21:01] <salgado> abentley, do we deploy stable to production?
[21:02] <abentley> salgado: yes.
[21:02] <salgado> then the last deployment was a big fuckup, it seems: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14860 is what got deployed
[21:03] <salgado> and that's a month old
[21:07] <abentley> salgado: So, I don't recall the details, but it's plausible that FDT rollouts are from db-stable, or that they involve merging db-stable into stable.
[21:08] <salgado> abentley, it magically went from r14860 to r15027 now
[21:08] <abentley> salgado: That's what the last NDT rollout was.
[21:09] <salgado> abentley, right, but for some time it was at r14860 and the workitems field had vanished: http://people.canonical.com/~salgado/lp-blueprints-without-workitems.png
[21:12] <salgado> abentley, looks like some appservers somehow have r14860.  discussing that in lp-ops
[22:10] <poolie> lifeless, hi
[23:17] <lifeless> poolie: hi