[00:00] wgrant: I was going to do my own QA first. [00:00] wgrant: one per person in the team [00:01] lifeless: No. [00:01] lifeless: TeamParticipation.person is constrained to me. And Person is contrained to TeamParticipation.team [00:01] So it's finding all of my teams that have subscriptions [00:02] to bug 1234 [00:02] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts < https://launchpad.net/bugs/1234 > [00:02] Right. [00:02] nested loop on TP though, which is a nuisance [00:02] if we're right [00:06] can teams have multiple subscriptions ? [00:07] ah it sthe order by [00:10] wgrant: will 8ms do ? [00:11] lifeless: Nah. [00:11] What'd you change? [00:11] couple of things [00:11] CTE [00:11] srsly? [00:11] plus narrower distinct by nested tables [00:11] For TP again? [00:11] https://pastebin.canonical.com/55155/ [00:11] just checking on wildcherry [00:12] 28 and 11 [00:12] checking old query [00:12] old query is 130ms on wildcherry consistently [00:13] 11ms new [00:13] consistently [00:16] wgrant: anyhow, context switching if you're finished with me ? [00:16] That indeed looks better. Odd. [00:16] Thanks. [00:17] https://pastebin.canonical.com/55156/ [00:17] is the new plan [00:18] wgrant: I'm not sure the distinct is needed [00:19] wgrant: unless teams can have multiple subscriptions to a bug [00:20] I'm not sure. [00:20] wgrant: the reason for the CTE is the 105 teams all did table walks on TP [00:20] Hah [00:20] if you look at the original plan [00:26] But we have to guess at what's expensive. And I can't test fixes :( [00:26] Because [00:26] Total runtime: 0.693 ms [02:12] who is reviewin today ? [02:15] StevenK: could you spare time to do a review? [02:16] https://code.launchpad.net/~lifeless/python-oops-datedir-repo/less-rsync/+merge/80861 [03:01] lifeless: Can do -- I was noming, sorry [03:01] StevenK: food? zomg NOOOOOOO [03:01] [thanks] [03:03] lifeless: r=me [03:04] thanks [03:04] I have another in a sec :) [03:04] lifeless: And wgrant is OCR today, but there is some silly horse race on. [03:04] yeah, wiki was down when I asked [03:08] StevenK: https://code.launchpad.net/~lifeless/python-oops-tools/amqp-polish/+merge/80864 in a minute or two [03:08] StevenK: and thanks! [03:12] StevenK: diff is up [03:13] I've already read it, just thinking [03:17] I can do a test for the upper if you want [03:17] though its one of those things that isn't going to break once its done [03:17] That's not my concern [03:17] :) [03:18] My concern is if there is a neater way to do it [03:18] we could reindex the 27M oops ids in the db with a functional index on upper() [03:19] Ew [03:19] Approvinated [03:19] thanks! [03:20] have you had an instant-oops yet ? [03:20] I've seen the new ids [03:20] heh, close :) [03:21] Personally, I think lp-oops.c.c needs to be better before I stop ssh'ing into carob to see OOPSes [03:21] its pleasant to hack on now [03:21] 6s test suite [03:21] etc [03:22] lifeless: Can I take output from subunit-ls and say to bin/test please run those [03:22] StevenK: yes [03:22] thats what testr run --failing does [03:22] the machinery is: [03:22] subunit-ls > list-file [03:22] bin/test --load-list list-file [03:22] I wonder if bin/test will like /dev/stdin as a list file [03:23] StevenK: it might, but ewww ;) [03:23] 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] Yeah, maybe I should just testr init, testr load, etc [03:33] ok, so thats deployed out; next thing, the workarounds for oops-amqp [03:33] almost need a fixed-amqplib [03:33] but I'm not quite there yet [03:40] Argh, model code updated by triggers [03:40] * StevenK claws his eyes out [03:40] StevenK: bug heat ? [03:40] lifeless: Branch.unique_name [03:41] * StevenK waits for his branch to stop WADLing [03:42] quack quack [03:56] * StevenK grumbles. [03:56] I suspect this branch is impossible with FDT. [03:57] jtv: O hai, can you QA r14202? [03:57] Hi StevenK [03:58] I'll get to it in a moment [04:00] StevenK: Are you still trying to rename +junk without talking to mrevell and others? [04:09] StevenK: i would like to be involved in planning what happens there [04:09] Renaming it is technically trivial. [04:09] Every other aspect of it is not trivial. [04:09] mostly trivial [04:09] depending on the new name + backward compat desires [04:10] i think we ought to at least think about the larger story of how projects get started and grow [04:10] some things in junk are purely personal [04:10] poolie: I think that hinders the local improvement [04:10] poolie: of just having a better na,e [04:10] others are nascent larger projects [04:10] A local improvement should be hindered. [04:10] Hey, can SSO grab from lp if a person is remote or not? [04:11] Because it is a large backwards-compatibility burden. [04:11] (for a sprint) [04:11] wgrant: only if it breaks +junk [04:11] lifeless: thinking about it does not hinder it [04:11] wgrant: which isn't presumed [04:11] lifeless: We now have to support +junk forever. [04:11] it's been like this for ~5 years [04:11] lifeless: Adding a new name means we have to support the new name forever too. [04:11] I shouldn't have said anything. I have work to do :) [04:12] congratulations on getting realtime oopses done [04:12] btw [04:13] thanks [04:13] StevenK: care to do https://code.launchpad.net/~lifeless/python-oops-amqp/0.0.4/+merge/80865 as well ? [04:16] StevenK: diff is there [04:20] wgrant: So its apparently pointless to do, then? [04:20] poolie: Involved how? [04:22] StevenK: when lp changes things like this that affect bzr, i'd appreciate being told beforehand [04:24] +junk is going away? [04:24] It is not. [04:24] no [04:24] Or going to be called something "better" [04:24] but there is broad consensus that its a horrible name [04:24] i'm heartily in favour of improving it and of looking for a small change that will improve it [04:24] what are you planning to do? [04:24] heh, agreed. [04:24] poolie: I'm planning on changing the code to return +personal by default, but accepting both +junk and +personal. [04:24] StevenK, we write documentation about launchpad and we answer a lot of questions about how to use it [04:25] and we make design decisions that work with launchpad [04:25] However, I'm not even sure if it's landable [04:25] so i think it's reasonable not to be surprised by changes there [04:25] Since there is a trigger involved. [04:25] ok [04:26] is this in an mp? i don't see any mail about it [04:26] StevenK: some care needed to check interactions with e.g. the apache rewrite map [04:26] StevenK: I think that uses that column [04:26] It's local only at this point. [04:26] that sounds like a good step though [04:26] a great step in fact [04:27] I think we should have a brief discussion with mrevell about the new url component [04:27] I'm in favour of something like 'p' [04:27] may as well make it not fugly [04:27] +p ? [04:27] no [04:27] p [04:28] We don't allow single character projects, do we? [04:28] exactly. [04:28] I'm not sure about p, TBH [04:28] p might be better reserved for project branches or something, but you get the idea [04:28] real-short-and-simple [04:29] I don't think + makes for a nice UI, never have. [04:30] i think according to https://dev.launchpad.net/LaunchpadEnhancementProposalProcess you need to write a lep for it [04:30] StevenK: https://code.launchpad.net/~lifeless/python-oops-amqp/0.0.4/+merge/80865 [04:30] 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] lifeless: Shall I just wait on IRC for your next MP? [04:30] StevenK: please [04:30] StevenK: that would be awesome [04:31] lifeless: Your timing the last two times has been impeccable [04:31] StevenK: blame your squadmate :) [04:31] I just swap my own work back in and I get pinged again. [04:31] I think I'll blame Melbourne. [04:31] StevenK: hey, I pinged this one 17 m back, but you were distracted :) [04:32] Oh, that one. [04:32] I already had it open, I was thinking. [04:34] lifeless: Approved, with a comment. [04:34] :/ [04:34] poolie? [04:34] 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] 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] yeah my unhappiness is basically that they don't ask when they see an impact [04:36] or perhaps they don't see an impact [04:36] poolie: How does the personal namespace impact on bzr? [04:37] for instance, we have documentation that refers to +junk [04:37] 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] but its compatible; any docs won't be invalidated, they will keep working. [04:37] yeah [04:37] Exactly [04:37] i guess that seems a bit pedantic to me [04:37] and it would be easy and more courteous to just say 'we're going to change this' in advance [04:38] poolie: Er, so I didn't even know if it was *possible* to change it until 4pm yesterday. [04:38] To be brutually honest, what I have is a play branch [04:38] 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] StevenK: how will you play WoW ? Oh right ... [04:39] * StevenK has removed that from his machines [04:40] Besides, I hated playing WoW with a trackpad [04:40] lifeless: i guess that example means "that had no changes that are likely to impact lp" [04:40] the difference is that changes to lp's ui/user model do impact us, because we document and support it [04:41] 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] 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] 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] i don't think it's about who's doing better or worse [04:43] 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] but rather, which things are useful to communicate about [04:43] if lp changes the namespace for branches that is the kind of thing i'd like to hear about [04:44] lifeless: Can we have a quick skype? [04:44] StevenK: sure [04:45] if there's any thing we're changing that you wish you'd heard about earlier, let me know [04:46] 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] yeah i normally do too [04:48] i was surprised by this because i didn't see anything about it on a bug or mp [04:51] 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] 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] jtv: OTP [04:52] ok [04:52] nigelb: I believe summit is the only user, so sure, though the data size can be pretty big on popular blueprints [04:53] lifeless: It has always been big. we hit issues with the 2 sprints thing this time. [04:54] Some BPs were only registered to LDS. [04:54] I'll change it after UDS, lest people murder me. [04:56] StevenK: result = store.find( [04:56] (Branch.id, Branch.unique_name), [04:56] Branch.unique_name.is_in(prefixes), [04:56] Branch.transitively_private == False).one() [04:59] Oh. [05:01] I just noticed rf-* is symblinked to the binary in devel. [05:04] StevenK, wgrant: mind if I upgrade dogfood? [05:09] when are builds deleted? like https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk/+build/12437 [05:09] are they gc'd a while after they complete? [05:11] jtv: No. [05:11] Thanks. [05:11] poolie: they're meant to never be deleted. [05:12] And I think I convinced code that deleting them was not going to work. [05:12] so the user must have deleted them? [05:12] So IIRC they shouldn't ever be deleted. [05:12] or the urls are just wrong [05:12] What linked to that? [05:12] https://bugs.launchpad.net/launchpad-buildd/+bug/693524 [05:12] <_mup_> Bug #693524: Daily builds fail because of insufficient memory < https://launchpad.net/bugs/693524 > [05:13] Perhaps they renamed the recipe? [05:13] D: [05:13] SPRB.destroySelf exists. [05:13] * wgrant goes stabbity stab. [05:13] for release in releases: [05:13] release.source_package_recipe_build = None [05:13] tergjkeriogjeroigteriogjioergioernjegkl [05:13] 23FTRWE89HGN A9PRGHERIUHGER [05:14] Yes that's right let's just erase the auditing information [05:14] WHY NOT [05:16] :) [05:19] 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] to make bzr-builder print them? [05:20] I'm not sure. [05:20] I would hesitate to suggest that a bzr-builder upgrade would be the easiest thing. [05:24] meaning "it probably is, but only slightly" or "it's probably not?" [05:24] I would have said it was, until we ran into this recent trouble. [05:24] Now it's possibly easier and safer to fix lp-buildd. [05:41] ftr this is the bug - https://bugs.launchpad.net/launchpad/+bug/147407 [05:41] <_mup_> Bug #147407: Junk sounds too harsh < https://launchpad.net/bugs/147407 > [05:51] ftr my bit is https://bugs.launchpad.net/launchpad/+bug/884092 [05:51] <_mup_> Bug #884092: source recipe build logs should mention versions used < https://launchpad.net/bugs/884092 > [07:08] 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] (The upload failure is something I've seen before — worth chasing down, but probably not worth holding up landings for) === jtv is now known as jtv-eat [07:13] so does buildd/buildrecipe somehow get copied to buildrecipe.py, which seemsto be the name that isactually run? [07:21] ok https://code.launchpad.net/~mbp/launchpad/884092-buildd-versions/+merge/80870 [07:22] stevenk, wrgant, how could i usefully locally test a change to buildrecipe? [07:24] poolie: there is a makefile in buildd, or a debian.rules - something [07:24] yeah, even some documentation [07:36] wgrant: OCR-ing today? [07:36] nigelb: Public holiday. [07:36] So I'm mostly not here. [07:36] wgrant: HA, what's the holiday for? (its holiday for us too) [07:37] Melbourne Cup [07:37] Because horse races are awesome, apparently. [07:37] Horse race? [07:37] lol [07:37] Ours is slightly more reasonable. State formation anniversary thingie. [07:41] wgrant: Do you get holidays for cricket matches as well? ;) [07:41] Nope. [07:41] Sad. [07:41] That obviously meant more hlidays. [07:42] No more make lint? [07:43] * nigelb moves to right folder. [07:51] Ugh, http://paste.ubuntu.com/725049/ [07:51] Tried out +temp-meeting-export locally. [07:52] Ah, that was my fail :) [07:57] * wallyworld_ off to see Cold Chisel :-) === jtv-eat is now known as jtv [08:05] Ew. This was done very badly. [08:05] For the meeting export, it gets all the sprint attendees and then gets people from it. === jtv is now known as jtv-afk [08:21] Could someone give some guidance on potential perfomance? [08:21] Currently, the meeting export fetches all the attendees for a summit and filters the people attending from that. [08:21] yup [08:22] so, the meeting export page is sort of fast. [08:22] this is an important characteristic [08:22] But the chnage I want kinda screws it up. [08:22] And I'm hesitant to do that :) [08:23] fair enough too :) [08:23] I wondering if we could add people to list as I find them [08:23] with the details I want [08:23] whats the big picture here [08:23] and build the list of people based on the people subscribed to the BPs in the sprint. [08:23] The big picture is we want all the people subscribed to a blueprint. [08:24] so the export should be 3 queries [08:24] -> sprint [08:24] -> blueprints [08:24] -> people [08:24] and then some glue [08:24] heh [08:24] Yeah [08:24] My idea is this [08:24] We do this currently [08:24] people_by_id = dict((person.id, person) for person in [08:24] getUtility(IPersonSet).getPrecachedPersonsFromIDs(attendee_set)) [08:25] and then we look into that dict to find a person's ID and whether they are required. [08:25] and \o/ instant oopses on staging as well [08:25] heh [08:25] I'm running it locally :) [08:25] lifeless: congrats! === jtv-afk is now known as jtv [08:25] rvba: thanks :) [08:26] lifeless: \o/ Nice :) [08:26] 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] 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] nigelb: thats about as bad as it gets [08:28] I was afraid of that :) [08:28] Alternatively, can I look up subscribers to a BP instead? [08:28] nigelb: step back [08:29] nigelb: you need three queries: [08:29] sprint [08:29] blueprints [08:29] peple [08:29] and then glue [08:29] the glue is mostly done - jus tneeds shuffling [08:29] I get all the people in launchpad? [08:29] you can't work with the object model for doing queries though: the object model is intrinsically hostile to performance [08:29] nigelb: no, you get all the people relevant to the blueprints [08:30] one query. [08:30] I can do that? [08:30] * nigelb didn't know. [08:30] well, you'll need to put the bits in the right order, but yes. [08:30] thats what the current code does (but it selects all attendees, not all subscribers-or-attendees) [08:31] [caveat, I haven' tlooked at that code in ~ 9 months, bzr annotate will tell you precisely when) [08:31] Is there code to do that or do you suggest I write it? :) [08:31] I don't know how much will need assembling and how much is pre canned [08:32] this is bread-and-butter to changing something in LP though, its not at all unordinary [08:32] Excellent. I'll look at the model and see if I can figure something out :) [08:32] I may need lots of help. [08:34] is this desirable? Won't the summit UI explode ? [08:34] No. [08:34] Summit was always doing this. [08:34] Showing all the subscribers to a BP. [08:34] It helps people hide the ones they aer not subscribed to. [08:35] And setup personal icals. [08:35] ok [08:35] so how is that data not present ? [08:35] all those break since some subscriptions don't get sycned thanks to two summits. [08:35] I don't understand the failure mode [08:35] We're using 2 launchpad sprints. [08:35] some Bps proposed to uds-p, some to lds [08:35] (Eventually, all blame goes to linaro :P) [08:35] but if you're using temp-meeting-export, that means you're not getting all subscriptions [08:36] we query both [08:36] so we get all subscriptions [08:36] But we don't get all the people [08:36] some people are registered for uds, some for lds. [08:36] I don't understand [08:36] neither export includes non-attendees [08:36] how are you getting 'all subscriberes to a BP' [08:37] Its from the export [08:37] I need to find out how james set this up. [08:37] so the export includes all subscribers irrespective of attendees ? [08:37] (at the summit end) [08:37] export does not. [08:37] then how is summit showing all subscribers ? [08:37] export includes only subscribers who are attendees. [08:38] Summit isn't showing all subscribers, which is what I'm digging for. [08:38] but you said 'summit was always doing this' [08:38] We always had one sprint. [08:38] 21:34 < lifeless> is this desirable? Won't the summit UI explode ? [08:38] 21:34 < nigelb> No. [08:38] 21:34 < nigelb> Summit was always doing this. [08:38] 21:34 < nigelb> Showing all the subscribers to a BP. [08:38] so, this was never a problem. [08:38] nigelb: one sprint doesn't mean showing all subscriberes [08:38] nigelb: the statements are not at all equivalent [08:38] lifeless: I'll rephrase. [08:39] Until now, we never noticed the impact. [08:39] Most Ubuntu folks were attendees. [08:39] right, and thats why I'm asking. [08:39] Won't the summit UI explode ? [08:39] explode in what sense? [08:41] 600 attendees [08:41] we don't show all attendees in one place. [08:41] But we show all subscribers to a BP. [08:41] bear with me [08:41] Yeah, I'm misunderstanding soething :) [08:42] Would skyping help? [08:47] ok, 597 subscribers across all bp;s [08:48] peaks is 46 [08:48] thats probably tolerable [08:48] (on a single spec) [08:48] hah, that. [08:48] Yeah. [08:48] We do occasionally have UI explosion for big and famous sessions [08:49] But its only if you mouse over. [08:52] lifeless: You just made me realize I need to dig deeper into summit for this. [08:52] Because with both the meetings, we should get all the subscriberes, but we're not. [08:52]