[00:00] <StevenK> wgrant: I was going to do my own QA first.
[00:00] <lifeless> wgrant: one per person in the team
[00:01] <wgrant> lifeless: No.
[00:01] <wgrant> lifeless: TeamParticipation.person is constrained to me. And Person is contrained to TeamParticipation.team
[00:01] <wgrant> So it's finding all of my teams that have subscriptions
[00:02] <lifeless> to bug 1234
[00:02] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[00:02] <wgrant> Right.
[00:02] <lifeless> nested loop on TP though, which is a nuisance
[00:02] <lifeless> if we're right
[00:06] <lifeless> can teams have multiple subscriptions ?
[00:07] <lifeless> ah it sthe order by
[00:10] <lifeless> wgrant: will 8ms do ?
[00:11] <wgrant> lifeless: Nah.
[00:11] <wgrant> What'd you change?
[00:11] <lifeless> couple of things
[00:11] <lifeless> CTE
[00:11] <wgrant> srsly?
[00:11] <lifeless> plus narrower distinct by nested tables
[00:11] <wgrant> For TP again?
[00:11] <lifeless> https://pastebin.canonical.com/55155/
[00:11] <lifeless> just checking on wildcherry
[00:12] <lifeless> 28 and 11
[00:12] <lifeless> checking old query
[00:12] <lifeless> old query is 130ms on wildcherry consistently
[00:13] <lifeless> 11ms new
[00:13] <lifeless> consistently
[00:16] <lifeless> wgrant: anyhow, context switching if you're finished with me ?
[00:16] <wgrant> That indeed looks better. Odd.
[00:16] <wgrant> Thanks.
[00:17] <lifeless> https://pastebin.canonical.com/55156/
[00:17] <lifeless> is the new plan
[00:18] <lifeless> wgrant: I'm not sure the distinct is needed
[00:19] <lifeless> wgrant: unless teams can have multiple subscriptions to a bug
[00:20] <wgrant> I'm not sure.
[00:20] <lifeless> wgrant: the reason for the CTE is the 105 teams all did table walks on TP
[00:20] <wgrant> Hah
[00:20] <lifeless> if you look at the original plan
[00:26] <wgrant> But we have to guess at what's expensive. And I can't test fixes :(
[00:26] <wgrant> Because
[00:26] <wgrant>  Total runtime: 0.693 ms
[02:12] <lifeless> who is reviewin today ?
[02:15] <lifeless> StevenK: could you spare time to do a review?
[02:16] <lifeless> https://code.launchpad.net/~lifeless/python-oops-datedir-repo/less-rsync/+merge/80861
[03:01] <StevenK> lifeless: Can do -- I was noming, sorry
[03:01] <lifeless> StevenK: food? zomg NOOOOOOO
[03:01] <lifeless> [thanks]
[03:03] <StevenK> lifeless: r=me
[03:04] <lifeless> thanks
[03:04] <lifeless> I have another in a sec :)
[03:04] <StevenK> lifeless: And wgrant is OCR today, but there is some silly horse race on.
[03:04] <lifeless> yeah, wiki was down when I asked
[03:08] <lifeless> StevenK: https://code.launchpad.net/~lifeless/python-oops-tools/amqp-polish/+merge/80864 in a minute or two
[03:08] <lifeless> StevenK: and thanks!
[03:12] <lifeless> StevenK: diff is up
[03:13] <StevenK> I've already read it, just thinking
[03:17] <lifeless> I can do a test for the upper if you want
[03:17] <lifeless> though its one of those things that isn't going to break once its done
[03:17] <StevenK> That's not my concern
[03:17] <lifeless> :)
[03:18] <StevenK> My concern is if there is a neater way to do it
[03:18] <lifeless> we could reindex the 27M oops ids in the db with a functional index on upper()
[03:19] <StevenK> Ew
[03:19] <StevenK> Approvinated
[03:19] <lifeless> thanks!
[03:20] <lifeless> have you had an instant-oops yet ?
[03:20] <StevenK> I've seen the new ids
[03:20] <lifeless> heh, close :)
[03:21] <StevenK> Personally, I think lp-oops.c.c needs to be better before I stop ssh'ing into carob to see OOPSes
[03:21] <lifeless> its pleasant to hack on now
[03:21] <lifeless> 6s test suite
[03:21] <lifeless> etc
[03:22] <StevenK> lifeless: Can I take output from subunit-ls and say to bin/test please run those
[03:22] <lifeless> StevenK: yes
[03:22] <lifeless> thats what testr run --failing does
[03:22] <lifeless> the machinery is:
[03:22] <lifeless> subunit-ls > list-file
[03:22] <lifeless> bin/test --load-list list-file
[03:22] <StevenK> I wonder if bin/test will like /dev/stdin as a list file
[03:23] <lifeless> StevenK: it might, but ewww ;)
[03:23] <lifeless> StevenK: you know you're reinventing testr by hand, right (AFAICT)
[03:23]  * StevenK tries it, just to make lifeless a little greener
[03:23] <StevenK> Yeah, maybe I should just testr init, testr load, etc
[03:33] <lifeless> ok, so thats deployed out; next thing, the workarounds for oops-amqp
[03:33] <lifeless> almost need a fixed-amqplib
[03:33] <lifeless> but I'm not quite there yet
[03:40] <StevenK> Argh, model code updated by triggers
[03:40]  * StevenK claws his eyes out
[03:40] <lifeless> StevenK: bug heat ?
[03:40] <StevenK> lifeless: Branch.unique_name
[03:41]  * StevenK waits for his branch to stop WADLing
[03:42] <lifeless> quack quack
[03:56]  * StevenK grumbles.
[03:56] <StevenK> I suspect this branch is impossible with FDT.
[03:57] <StevenK> jtv: O hai, can you QA r14202?
[03:57] <jtv> Hi StevenK
[03:58] <jtv> I'll get to it in a moment
[04:00] <wgrant> StevenK: Are you still trying to rename +junk without talking to mrevell and others?
[04:09] <poolie> StevenK: i would like to be involved in planning what happens there
[04:09] <wgrant> Renaming it is technically trivial.
[04:09] <wgrant> Every other aspect of it is not trivial.
[04:09] <lifeless> mostly trivial
[04:09] <lifeless> depending on the new name +  backward compat desires
[04:10] <poolie> i think we ought to at least think about the larger story of how projects get started and grow
[04:10] <poolie> some things in junk are purely personal
[04:10] <lifeless> poolie: I think that hinders the local improvement
[04:10] <lifeless> poolie: of just having a better na,e
[04:10] <poolie> others are nascent larger projects
[04:10] <wgrant> A local improvement should be hindered.
[04:10] <nigelb> Hey, can SSO grab from lp if a person is remote or not?
[04:11] <wgrant> Because it is a large backwards-compatibility burden.
[04:11] <nigelb> (for a sprint)
[04:11] <lifeless> wgrant: only if it breaks +junk
[04:11] <poolie> lifeless: thinking about it does not hinder it
[04:11] <lifeless> wgrant: which isn't presumed
[04:11] <wgrant> lifeless: We now have to support +junk forever.
[04:11] <poolie> it's been like this for ~5 years
[04:11] <wgrant> lifeless: Adding a new name means we have to support the new name forever too.
[04:11] <lifeless> I shouldn't have said anything. I have work to do :)
[04:12] <poolie> congratulations on getting realtime oopses done
[04:12] <poolie> btw
[04:13] <lifeless> thanks
[04:13] <lifeless> StevenK: care to do https://code.launchpad.net/~lifeless/python-oops-amqp/0.0.4/+merge/80865 as well ?
[04:16] <lifeless> StevenK: diff is there
[04:20] <StevenK> wgrant: So its apparently pointless to do, then?
[04:20] <StevenK> poolie: Involved how?
[04:22] <poolie> StevenK: when lp changes things like this that affect bzr, i'd appreciate being told beforehand
[04:24] <nigelb> +junk is going away?
[04:24] <StevenK> It is not.
[04:24] <lifeless> no
[04:24] <nigelb> Or going to be called something "better"
[04:24] <lifeless> but there is broad consensus that its a horrible name
[04:24] <poolie> i'm heartily in favour of improving it and of looking for a small change that will improve it
[04:24] <poolie> what are you planning to do?
[04:24] <nigelb> heh, agreed.
[04:24] <StevenK> poolie: I'm planning on changing the code to return +personal by default, but accepting both +junk and +personal.
[04:24] <poolie> StevenK, we write documentation about launchpad and we answer a lot of questions about how to use it
[04:25] <poolie> and we make design decisions that work with launchpad
[04:25] <StevenK> However, I'm not even sure if it's landable
[04:25] <poolie> so i think it's reasonable not to be surprised by changes there
[04:25] <StevenK> Since there is a trigger involved.
[04:25] <poolie> ok
[04:26] <poolie> is this in an mp? i don't see any mail about it
[04:26] <lifeless> StevenK: some care needed to check interactions with e.g. the apache rewrite map
[04:26] <lifeless> StevenK: I think that uses that column
[04:26] <StevenK> It's local only at this point.
[04:26] <poolie> that sounds like a good step though
[04:26] <poolie> a great step in fact
[04:27] <lifeless> I think we should have a brief discussion with mrevell about the new url component
[04:27] <lifeless> I'm in favour of something like 'p'
[04:27] <lifeless> may as well make it not fugly
[04:27] <StevenK> +p ?
[04:27] <lifeless> no
[04:27] <lifeless> p
[04:28] <StevenK> We don't allow single character projects, do we?
[04:28] <lifeless> exactly.
[04:28] <StevenK> I'm not sure about p, TBH
[04:28] <lifeless> p might be better reserved for project branches or something, but you get the idea
[04:28] <lifeless> real-short-and-simple
[04:29] <lifeless> I don't think + makes for a nice UI, never have.
[04:30] <poolie> i think according to https://dev.launchpad.net/LaunchpadEnhancementProposalProcess you need to write a lep for it
[04:30] <lifeless> StevenK: https://code.launchpad.net/~lifeless/python-oops-amqp/0.0.4/+merge/80865
[04:30] <StevenK> So sinzui said on the call that +personal seems to be the prefered name, and that I can have a free rs=sinzui so he copes the flak and I don't. :-P
[04:30] <StevenK> lifeless: Shall I just wait on IRC for your next MP?
[04:30] <lifeless> StevenK: please
[04:30] <lifeless> StevenK: that would be awesome
[04:31] <StevenK> lifeless: Your timing the last two times has been impeccable
[04:31] <lifeless> StevenK: blame your squadmate :)
[04:31] <StevenK> I just swap my own work back in and I get pinged again.
[04:31] <StevenK> I think I'll blame Melbourne.
[04:31] <lifeless> StevenK: hey, I pinged this one 17 m back, but you were distracted :)
[04:32] <StevenK> Oh, that one.
[04:32] <StevenK> I already had it open, I was thinking.
[04:34] <StevenK> lifeless: Approved, with a comment.
[04:34] <poolie> :/
[04:34] <StevenK> poolie?
[04:34] <lifeless> poolie: I think you're asking for more from LP devs than they ask from bzr here, and I don't understand why.
[04:35] <lifeless> poolie: both project cooperate, have a reasonable understanding of the other (at least at team mgmt levels) so they ask when they see impact, and don't when they don't.
[04:36] <poolie> yeah my unhappiness is basically that they don't ask when they see an impact
[04:36] <poolie> or perhaps they don't see an impact
[04:36] <StevenK> poolie: How does the personal namespace impact on bzr?
[04:37] <poolie> for instance, we have documentation that refers to +junk
[04:37] <lifeless> So, imagine that we accept +personal and +junk, and advertise +personal. That obviously needs to be socialised amongst everyone doing support, and all our useres.
[04:37] <lifeless> but its compatible; any docs won't be invalidated, they will keep working.
[04:37] <poolie> yeah
[04:37] <StevenK> Exactly
[04:37] <poolie> i guess that seems a bit pedantic to me
[04:37] <poolie> and it would be easy and more courteous to just say 'we're going to change this' in advance
[04:38] <StevenK> poolie: Er, so I didn't even know if it was *possible* to change it until 4pm yesterday.
[04:38] <StevenK> To be brutually honest, what I have is a play branch
[04:38] <lifeless> would you tell LP if you added a new verb with no particularly surprising semantics in it, that was backwards compatible with old clients etc?
[04:39]  * StevenK throws his Dell laptop out the window
[04:39] <lifeless> StevenK: how will you play WoW ? Oh right ...
[04:39]  * StevenK has removed that from his machines
[04:40] <StevenK> Besides, I hated playing WoW with a trackpad
[04:40] <poolie> lifeless: i guess that example means "that had no changes that are likely to impact lp"
[04:40] <poolie> the difference is that changes to lp's ui/user model do impact us, because we document and support it
[04:41] <poolie> StevenK: np, i don't really mind this case (and again, i'm happy to see it improved) it just seemed like a bit of a pattern
[04:42] <lifeless> poolie: what data points are on this pattern? Last time we spoke about this feeling you were hard put to pin it down.
[04:42] <lifeless> poolie: it *seemed*, as I remember it, to be mainly feeling that LP did stuff without talking about it : but when we compared notes team bzr wasn't communicating (in advance) any more fully
[04:43] <poolie> i don't think it's about who's doing better or worse
[04:43] <lifeless> poolie: I don't mean to frame this as what you do vs what lp does, though it seems I'm taking it that way
[04:43] <poolie> but rather, which things are useful to communicate about
[04:43] <poolie> if lp changes the namespace for branches that is the kind of thing i'd like to hear about
[04:44] <StevenK> lifeless: Can we have a quick skype?
[04:44] <lifeless> StevenK: sure
[04:45] <poolie> if there's any thing we're changing that you wish you'd heard about earlier, let me know
[04:46] <lifeless> poolie: I trust that (I track what you are doing enough, and that you make good decisions) to the extent that whatever falls through the cracks, falls through the cracks.
[04:48] <poolie> yeah i normally do too
[04:48] <poolie> i was surprised by this because i didn't see anything about it on a bug or mp
[04:51] <nigelb> Hi, so +temp-meeting-export will not give a subscription information if someone is not registered for a sprint. Is there a chance I can remove that check?
[04:51] <jtv> StevenK: I need to make dogfood or staging go through the motions of notifying about a package sync or upload…  I can't sync Ubuntu packages on dogfood any more; what would I need to do to elicit an email notification from an upload?
[04:52] <StevenK> jtv: OTP
[04:52] <jtv> ok
[04:52] <lifeless> nigelb: I believe summit is the only user, so sure, though the data size can be pretty big on popular blueprints
[04:53] <nigelb> lifeless: It has always been big. we hit issues with the 2 sprints thing this time.
[04:54] <nigelb> Some BPs were only registered to LDS.
[04:54] <nigelb> I'll change it after UDS, lest people murder me.
[04:56] <lifeless> StevenK:         result = store.find(
[04:56] <lifeless>             (Branch.id, Branch.unique_name),
[04:56] <lifeless>             Branch.unique_name.is_in(prefixes),
[04:56] <lifeless>             Branch.transitively_private == False).one()
[04:59] <nigelb> Oh.
[05:01] <nigelb> I just noticed rf-* is symblinked to the binary in devel.
[05:04] <jtv> StevenK, wgrant: mind if I upgrade dogfood?
[05:09] <poolie> when are builds deleted? like https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk/+build/12437
[05:09] <poolie> are they gc'd a while after they complete?
[05:11] <wgrant> jtv: No.
[05:11] <jtv> Thanks.
[05:11] <wgrant> poolie: they're meant to never be deleted.
[05:12] <wgrant> And I think I convinced code that deleting them was not going to work.
[05:12] <poolie> so the user must have deleted them?
[05:12] <wgrant> So IIRC they shouldn't ever be deleted.
[05:12] <poolie> or the urls are just wrong
[05:12] <wgrant> What linked to that?
[05:12] <poolie> https://bugs.launchpad.net/launchpad-buildd/+bug/693524
[05:12] <_mup_> Bug #693524: Daily builds fail because of insufficient memory <escalated> <linaro> <recipe> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/693524 >
[05:13] <wgrant> Perhaps they renamed the recipe?
[05:13] <wgrant> D:
[05:13] <wgrant> SPRB.destroySelf exists.
[05:13]  * wgrant goes stabbity stab.
[05:13] <wgrant>         for release in releases:
[05:13] <wgrant>             release.source_package_recipe_build = None
[05:13] <wgrant> tergjkeriogjeroigteriogjioergioernjegkl
[05:13] <wgrant> 23FTRWE89HGN A9PRGHERIUHGER
[05:14] <wgrant> Yes that's right let's just erase the auditing information
[05:14] <wgrant> WHY NOT
[05:16] <poolie> :)
[05:19] <poolie> wgrant: what would be the most practical way for me to get the versions of bzr and bzr-builder in to the build log file
[05:19] <poolie> to make bzr-builder print them?
[05:20] <wgrant> I'm not sure.
[05:20] <wgrant> I would hesitate to suggest that a bzr-builder upgrade would be the easiest thing.
[05:24] <poolie> meaning "it probably is, but only slightly" or "it's probably not?"
[05:24] <wgrant> I would have said it was, until we ran into this recent trouble.
[05:24] <wgrant> Now it's possibly easier and safer to fix lp-buildd.
[05:41] <lifeless> ftr this is the bug - https://bugs.launchpad.net/launchpad/+bug/147407
[05:41] <_mup_> Bug #147407: Junk sounds too harsh <lp-code> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/147407 >
[05:51] <poolie> ftr my bit is https://bugs.launchpad.net/launchpad/+bug/884092
[05:51] <_mup_> Bug #884092: source recipe build logs should mention versions used <Launchpad itself:Triaged> < https://launchpad.net/bugs/884092 >
[07:08] <jtv> StevenK: not having much luck testing that revision.  Can't even upload a deb to dogfood.  :(  Since my branch doesn't change any functionality, I think I'll go with "qa-untestable."
[07:09] <jtv> (The upload failure is something I've seen before — worth chasing down, but probably not worth holding up landings for)
[07:13] <poolie> so does buildd/buildrecipe somehow get copied to buildrecipe.py, which seemsto be the name that isactually run?
[07:21] <poolie> ok https://code.launchpad.net/~mbp/launchpad/884092-buildd-versions/+merge/80870
[07:22] <poolie> stevenk, wrgant, how could i usefully locally test a change to buildrecipe?
[07:24] <lifeless> poolie: there is a makefile in buildd, or a debian.rules - something
[07:24] <poolie> yeah, even some documentation
[07:36] <nigelb> wgrant: OCR-ing today?
[07:36] <wgrant> nigelb: Public holiday.
[07:36] <wgrant> So I'm mostly not here.
[07:36] <nigelb> wgrant: HA, what's the holiday for? (its holiday for us too)
[07:37] <wgrant> Melbourne Cup
[07:37] <wgrant> Because horse races are awesome, apparently.
[07:37] <nigelb> Horse race?
[07:37] <nigelb> lol
[07:37] <nigelb> Ours is slightly more reasonable. State formation anniversary thingie.
[07:41] <nigelb> wgrant: Do you get holidays for cricket matches as well? ;)
[07:41] <wgrant> Nope.
[07:41] <nigelb> Sad.
[07:41] <nigelb> That obviously meant more hlidays.
[07:42] <nigelb> No more make lint?
[07:43]  * nigelb moves to right folder.
[07:51] <nigelb> Ugh, http://paste.ubuntu.com/725049/
[07:51] <nigelb> Tried out +temp-meeting-export locally.
[07:52] <nigelb> Ah, that was my fail :)
[07:57]  * wallyworld_ off to see Cold Chisel :-)
[08:05] <nigelb> Ew. This was done very badly.
[08:05] <nigelb> For the meeting export, it gets all the sprint attendees and then gets people from it.
[08:21] <nigelb> Could someone give some guidance on potential perfomance?
[08:21] <nigelb> Currently, the meeting export fetches all the attendees for a summit and filters the people attending from that.
[08:21] <lifeless> yup
[08:22] <nigelb> so, the meeting export page is sort of fast.
[08:22] <lifeless> this is an important characteristic
[08:22] <nigelb> But the chnage I want kinda screws it up.
[08:22] <nigelb> And I'm hesitant to do that :)
[08:23] <lifeless> fair enough too :)
[08:23] <nigelb> I wondering if we could add people to list as I find them
[08:23] <nigelb> with the details I want
[08:23] <lifeless> whats the big picture here
[08:23] <nigelb> and build the list of people based on the people subscribed to the BPs in the sprint.
[08:23] <nigelb> The big picture is we want all the people subscribed to a blueprint.
[08:24] <lifeless> so the export should be 3 queries
[08:24] <lifeless> -> sprint
[08:24] <lifeless> -> blueprints
[08:24] <lifeless> -> people
[08:24] <lifeless> and then some glue
[08:24] <nigelb> heh
[08:24] <nigelb> Yeah
[08:24] <nigelb> My idea is this
[08:24] <nigelb> We do this currently
[08:24] <nigelb>         people_by_id = dict((person.id, person) for person in
[08:24] <nigelb>             getUtility(IPersonSet).getPrecachedPersonsFromIDs(attendee_set))
[08:25] <nigelb> and then we look into that dict to find a person's ID and whether they are required.
[08:25] <lifeless> and \o/ instant oopses on staging as well
[08:25] <nigelb> heh
[08:25] <nigelb> I'm running it locally :)
[08:25] <rvba> lifeless: congrats!
[08:25] <lifeless> rvba: thanks :)
[08:26] <nigelb> lifeless: \o/ Nice :)
[08:26] <lifeless> rvba: allenap: btw - you might like the last commit on oops-amqp - more errors amqplib throws up when rabbits are restsarted
[08:26]  * rvba looks.
[08:27] <nigelb> lifeless: Ideally, I'd like to look if a person exists in a dict I create as I go, if not lookup each person I find on a BP, and find their ID, name, required status and put into that dict.  I'll be quering more on launchpad, but only once person.  Is that too much of a perf drop?
[08:28] <lifeless> nigelb: thats about as bad as it gets
[08:28] <nigelb> I was afraid of that :)
[08:28] <nigelb> Alternatively, can I look up subscribers to a BP instead?
[08:28] <lifeless> nigelb: step back
[08:29] <lifeless> nigelb: you need three queries:
[08:29] <lifeless> sprint
[08:29] <lifeless> blueprints
[08:29] <lifeless> peple
[08:29] <lifeless> and then glue
[08:29] <lifeless> the glue is mostly done - jus tneeds shuffling
[08:29] <nigelb> I get all the people in launchpad?
[08:29] <lifeless> you can't work with the object model for doing queries though: the object model is intrinsically hostile to performance
[08:29] <lifeless> nigelb: no, you get all the people relevant to the blueprints
[08:30] <lifeless> one query.
[08:30] <nigelb> I can do that?
[08:30]  * nigelb didn't know.
[08:30] <lifeless> well, you'll need to put the bits in the right order, but yes.
[08:30] <lifeless> thats what the current code does (but it selects all attendees, not all subscribers-or-attendees)
[08:31] <lifeless> [caveat, I haven' tlooked at that code in ~ 9 months, bzr annotate will tell you precisely when)
[08:31] <nigelb> Is there code to do that or do you suggest I write it? :)
[08:31] <lifeless> I don't know how much will need assembling and how much is pre canned
[08:32] <lifeless> this is bread-and-butter to changing something in LP though, its not at all unordinary
[08:32] <nigelb> Excellent. I'll look at the model and see if I can figure something out :)
[08:32] <nigelb> I may need lots of help.
[08:34] <lifeless> is this desirable? Won't the summit UI explode ?
[08:34] <nigelb> No.
[08:34] <nigelb> Summit was always doing this.
[08:34] <nigelb> Showing all the subscribers to a BP.
[08:34] <nigelb> It helps people hide the ones they aer not subscribed to.
[08:35] <nigelb> And setup personal icals.
[08:35] <lifeless> ok
[08:35] <lifeless> so how is that data not present ?
[08:35] <nigelb> all those break since some subscriptions don't get sycned thanks to two summits.
[08:35] <lifeless> I don't understand the failure mode
[08:35] <nigelb> We're using 2 launchpad sprints.
[08:35] <nigelb> some Bps proposed to uds-p, some to lds
[08:35] <nigelb> (Eventually, all blame goes to linaro :P)
[08:35] <lifeless> but if you're using temp-meeting-export, that means you're not getting all subscriptions
[08:36] <nigelb> we query both
[08:36] <nigelb> so we get all subscriptions
[08:36] <nigelb> But we don't get all the people
[08:36] <nigelb> some people are registered for uds, some for lds.
[08:36] <lifeless> I don't understand
[08:36] <lifeless> neither export includes non-attendees
[08:36] <lifeless> how are you getting 'all subscriberes to a BP'
[08:37] <nigelb> Its from the export
[08:37] <nigelb> I need to find out how james set this up.
[08:37] <lifeless> so the export includes all subscribers irrespective of attendees ?
[08:37] <nigelb> (at the summit end)
[08:37] <nigelb> export does not.
[08:37] <lifeless> then how is summit showing all subscribers ?
[08:37] <nigelb> export includes only subscribers who are attendees.
[08:38] <nigelb> Summit isn't showing all subscribers, which is what I'm digging for.
[08:38] <lifeless> but you said 'summit was always doing this'
[08:38] <nigelb> We always had one sprint.
[08:38] <lifeless> 21:34 < lifeless> is this desirable? Won't the summit UI explode ?
[08:38] <lifeless> 21:34 < nigelb> No.
[08:38] <lifeless> 21:34 < nigelb> Summit was always doing this.
[08:38] <lifeless> 21:34 < nigelb> Showing all the subscribers to a BP.
[08:38] <nigelb> so, this was never a problem.
[08:38] <lifeless> nigelb: one sprint doesn't mean showing all subscriberes
[08:38] <lifeless> nigelb: the statements are not at all equivalent
[08:38] <nigelb> lifeless: I'll rephrase.
[08:39] <nigelb> Until now, we never noticed the impact.
[08:39] <nigelb> Most Ubuntu folks were attendees.
[08:39] <lifeless> right, and thats why I'm asking.
[08:39] <lifeless> Won't the summit UI explode ?
[08:39] <nigelb> explode in what sense?
[08:41] <lifeless> 600 attendees
[08:41] <nigelb> we don't show all attendees in one place.
[08:41] <nigelb> But we show all subscribers to a BP.
[08:41] <lifeless> bear with me
[08:41] <nigelb> Yeah, I'm misunderstanding soething :)
[08:42] <nigelb> Would skyping help?
[08:47] <lifeless> ok, 597 subscribers across all bp;s
[08:48] <lifeless> peaks is 46
[08:48] <lifeless> thats probably tolerable
[08:48] <lifeless> (on a single spec)
[08:48] <nigelb> hah, that.
[08:48] <nigelb> Yeah.
[08:48] <nigelb> We do occasionally have UI explosion for big and famous sessions
[08:49] <nigelb> But its only if you mouse over.
[08:52] <nigelb> lifeless: You just made me realize I need to dig deeper into summit for this.
[08:52] <nigelb> Because with both the meetings, we should get all the subscriberes, but we're not.
[08:52] <lifeless> nigelb: consider the more permanent solution :)
[08:53] <nigelb> lifeless: I like what's currently there for its performance :)
[08:53] <nigelb> I probably only wold add a warning when subscribing that "You aren't markd as attending for this sprint" or osmething.
[09:20] <allenap> lifeless: Yes, tip top, thanks.
[09:21] <lifeless> allenap: also the current catch IOError in LP is too broad
[09:21] <lifeless> allenap: (again, see oops-amqp for better handling of that)
[09:22] <allenap> lifeless: rvba has been working on that, but is suffering badly from a Heisenbug around OOPSes. I suspect the big OOPS landing yesterday might help.
[09:23] <rvba> allenap: I tried to use the new oops thing yesterday and land it again, but I've been suffering from the perf problem lifeless mentioned in his email and I killed it after 6 hours in ec2.
[09:24] <lifeless> rvba: its fixed now :)
[09:24] <rvba> lifeless: \o/.  I shall try to land it again then. Thanks for the heads up.
[09:24] <lifeless> if it takes that long its your change :P
[09:25]  * rvba tries to land it again.
[11:32] <bigjools> gmb: can I bother thee for a review please
[11:32] <gmb> bigjools: Sure. I'll take a look as soon as I've done with rvba's.
[11:32] <bigjools> thanks
[12:28] <bigjools> gmb: heh, good point with the comments
[12:28] <gmb> :)
[12:28] <bigjools> I only even added those ones as an afterthought - never a good idea
[12:58] <deryck> Morning, all.
[13:16] <danhg> Hi Everyone, if you're a Launchpad user, please get in touch if you'd like to do some usability testing today.
[13:19] <lifeless> danhg: I suggest trying in #ubuntu-uds
[13:19] <danhg> thanks lifeless
[13:19] <lifeless> danhg: folk here probably don't qualify for such tests :P
[13:20] <danhg> I've posted there too
[13:20] <lifeless> danhg: I don't see you in that channel ?
[13:20] <danhg> I'm in it now
[13:21] <danhg> I'm on Colloquy. It likes to mess around.
[13:21] <lifeless> indeed, you are too
[14:24] <rvba> lifeless: Your new oopses code fixed my Heisenbug.  Thank you for that!
[14:25] <lifeless> \o/
[14:25] <lifeless> how?
[14:26] <rvba> I don't know (hence the Heisenbug), but I was able to land my code without a problem once I've refactored it to use the new oops code.
[14:26] <rvba> I had this weird 'test hung' failure.
[14:26] <rvba> That I could not reproduce locally.
[14:32] <rvba> lifeless: If you're really interested, you have all the details about the Heisenbug in my email "Help with a hung test" to the mailing list.
[14:33] <Beret> lifeless, thought you were going to bed? :)
[14:34] <lifeless> I was
[14:34] <lifeless> I am too :P
[14:34] <lifeless> rvba: were you using getLastOops ?
[14:34] <rvba> lifeless: yes.
[14:34] <lifeless> then you were seeing an oops from the test before, in all probability
[14:35] <lifeless> because it was a terrrrrible API (though probably not obviously so at the time it was written)
[14:35] <lifeless> rvba: I'm glad its working for you
[14:35] <lifeless> and with that, I really am halt()ing state
[14:35] <rvba> Good night lifeless!
[14:42] <rvba> gmb: I've got a tiny review for you if you're up for it ;). https://code.launchpad.net/~rvb/launchpad/combinator-bug-881144/+merge/80911
[14:42] <gmb> rvba: I'm OTP and then am going to be grabbing a late lunch, but I'll come to it soon thereafter.
[14:43] <rvba> gmb: sure. Thank you!
[15:04] <deryck> abentley, should we do a late standup now, while I wait on staging update?
[15:04] <abentley> deryck: sure.
[15:08] <deryck> abentley, http://pastebin.ubuntu.com/725330/
[15:25] <deryck> abentley, we will need to get a loading spinner of some sort working when changing the ordering.
[15:25] <deryck> abentley, but I think we'll need to rethink our current spinner approach since a whole section of the page changes.
[15:25] <abentley> deryck: We haven't implemented precaching yet :-)  Well, I guess we should add a spinner anyhow.
[15:26] <deryck> abentley, yeah, just to be safe.
[15:26] <deryck> mrevell, staging is working now.  https://bugs.staging.launchpad.net/launchpad/+bugs
[15:26] <mrevell> Woooo! Thanks deryck
[15:26] <deryck> mrevell, np.
[15:27] <deryck> mrevell, some minor issues still, like needing a loading symbol to indicate we're getting results, but overall, the resorting is pretty darn cool.
[15:27] <deryck> but after the initial load, it's super fast.
[15:27] <mrevell> deryck, Cool :) What team do I need to be in the thing?
[15:28] <mrevell> Sorry, that made little sense.
[15:28] <deryck> mrevell, I think matsubara added the product team to the feature flag rule.
[15:28] <mrevell> I'm not seeing the new listings so I'll hunt him down and ask him to pop me in the relevant team. Cheers.
[15:29] <deryck> mrevell, cool.  cheers.
[15:29] <abentley> deryck: very nice.
[15:30] <deryck> thanks, abentley!
[15:57] <jml> mrevell: in this ask ubuntu session, you'd be amazed at how much people are talking about 'reputation' (their karma equiv.) as a desirable commodity and a motivator for actions.
[16:45] <gmb> rvba: I haven't had chance to review your branch yet, but I will do before I EoD.
[16:46] <rvba> gmb: Great, it's not urgent so if you don't have the time today that's fine, I'll get it reviewed tomorrow.
[16:47] <gmb> rvba: Okay, thanks. I'll do my best though. Interviews are sucking up a lot of time for team Yellow this week.
[21:18] <mrevell> hey huwshimi
[21:18] <thumper> hi mrevell
[21:18] <huwshimi> mrevell: Morning!
[21:18] <thumper> mrevell: you in orlando?
[21:20] <thumper> mrevell: is sinzui there with you?
[21:21] <thumper> I'd like to talk privacy with him
[21:21] <mrevell> thumper, sinzui is here, he arrived today
[21:21] <mrevell> thumper, and "hello" :)
[21:21] <mrevell> huwshimi, Hey, do you want to have a catch-up call?
[21:22] <mrevell> thumper, I'm not sure where he is right now but I can let him know you want to talk.
[21:22] <thumper> mrevell: that'd be cool
[21:22] <huwshimi> mrevell: Sure
[21:22] <thumper> mrevell: I'm back home now though, so it would have to be afternoon for him
[21:22] <huwshimi> mrevell: 5 mins?
[21:23] <mrevell> thumper, Okeydoke. I'll let him know to contact you when I see him.
[21:23] <mrevell> huwshimi, Sure.
[21:23] <lifeless> mrevell: allo
[21:23] <mrevell> hello lifeless
[21:25] <jelmer> hi launchpadders
[21:27] <lifeless> mrevell: have you seen the new LessJunk LEP? I haven't read it yet but given that the implementation is pretty shallow it would be worth us working through the questions I expect it raises.
[21:29] <huwshimi> mrevell: Ready when you are
[21:29] <mrevell> lifeless, I've seen that it exists but not yet read it; it's been pretty full on today and yesterday. I'll take a look tonight or tomorrow morning and perhaps we can have a call tomorrow.
[21:30] <mrevell> huwshimi, Cool. Is Skype okay?
[21:30] <huwshimi> mrevell: yup
[21:30] <lifeless> mrevell: sweet
[21:33] <huwshimi> mrevell: I'm getting nothing
[21:34] <mrevell> huwshimi, Oh, weird. It was ringing for me. I'll try again
[21:34] <huwshimi> mrevell: It rang and I answered, but no sound
[21:34] <huwshimi> mrevell: Oh, looks like skype crashed
[21:36] <huwshimi> mrevell: Try again?
[21:41] <lifeless> flacoste: dunno if you saw, but wgrant shaved a second off of ubuntu bug searches
[21:42] <lifeless> flacoste: maybe more in fact - poor behaviour on the TeamParticipation table
[21:42] <lifeless> flacoste: I going to ask stub to look into some pg innards relating to this
[21:42] <flacoste> lifeless: i saw mention of a performance related feature flag earlier
[21:42] <flacoste> didn't know the details
[21:42] <flacoste> but that's excellent
[21:42] <lifeless> its a bit worrying, but good we have a workaround - I suspect table and index bloat on the table
[21:44] <lifeless> flacoste: also \o/ \o/ \o/ I'm so happy the major part of the oops arc is complete.
[21:48] <flacoste> yes, this is also awesome news!
[21:48] <lifeless> I know I mentioned it yesterday, but I'm still bouncy from it ;)
[21:54] <poolie> flacoste, all
[21:54] <flacoste> hi poolie
[22:59] <poolie> hi huwshimi?
[23:37] <poolie> lifeless, huw, i wonder if there should be some kind of systematic answer to whether to provide counts of objects from the thing that links to them
[23:37] <poolie> like rvb's recent bug 827935
[23:37] <_mup_> Bug #827935: Person:+branches timeouts <regression> <timeout> <Launchpad itself:In Progress by rvb> < https://launchpad.net/bugs/827935 >
[23:37] <poolie> perhaps it's just simply: do it if it's useful but not if it's too expensive
[23:43] <lifeless> I think it depends a lot on context
[23:43] <lifeless> for instance, a dashboard telling you what things need doing it much more useful if you don't need to click through
[23:44] <lifeless> the portlet showing high/critical/untriaged/my bugs for instance - the first three tell you things you need to action, the last one is more 'canned search' - if you see what I mean
[23:48] <wgrant> lifeless: Is lp-oops missing its 500.html again?
[23:48] <lifeless> wgrant: it hasn't been added ever
[23:48] <lifeless> wgrant: its barfing on the index page?
[23:48] <wgrant> Yes.
[23:48] <wgrant> And all other pages.
[23:48] <wgrant> Ah, no, some OOPSes work.
[23:49] <lifeless> should wire it up with oops reporting
[23:49] <wgrant> Heh
[23:50] <lifeless> ./src/oopstools/settings.py:INDEX_TEMPLATE = "index-launchpad.html"
[23:50] <poolie> lifeless: yeah i like the new/high/critical things
[23:50] <StevenK> And then if the OOPS reporting causes an OOPS while reporting an OOPS, we reboot Launchpad.
[23:58] <lifeless> wgrant: should be fixed