[00:46] wgrant: The removal of self.log(self._output.output) is needed? [00:46] (From lp-dev-utils) [00:58] StevenK: I'm not sure what the real fix is, I just quickly deleted the line in the traceback to get ec2 to work. [01:00] I have another change to make, so I'll ignore that removal for now [01:06] [2013-05-08 00:58:14,724: INFO/PoolWorker-3] Job resulted in OOPS: OOPS-f707f73e2b097961847648306d155654 [01:06] InternalError: current transaction is aborted, commands ignored until end of transaction block [01:07] There was an earlier OOPS [01:07] Not that I can see in the log [01:11] wgrant: So, unscan-branch or delete and repush? === tasdomas is now known as tasdomas_afk === tasdomas_afk is now known as tasdomas [01:49] flacoste: Are you using Chromium to get those librarian 404s? === tasdomas is now known as tasdomas_afk [02:23] StevenK: What's the new DB MP? [02:26] I had to delete them because sync-pipeline completly lost its mind [02:28] wgrant: Right, all six MPs are up, all with diffs. [02:28] StevenK: Only six? I'm disappointed. [02:28] Will look soon [03:15] StevenK: 350 + def findBranchMergeProposalIDs(self): [03:15] 351 + return self.store.find( [03:15] 352 + (BranchMergeProposal.id), [03:15] That doesn't do what you think it does [03:15] () is an empty tuple, but (foo) is just foo [03:36] wgrant: The garbo job actually works, though ... [03:38] StevenK: But the code still doesn't mean what you intended, so probably best to drop the parens. [03:38] wgrant: Right. [03:39] wgrant: Killing yui_3.3.0.zip from sourcedeps, should yui_3.5.1.zip also meet its demise? [03:39] StevenK: Might as well [03:46] wgrant: Fix for http://pastebin.ubuntu.com/5643581/ landing/landed. [03:55] wgrant: Your comment about removing merge_proposal_id is on the right MP? [03:58] Oh [03:58] Why? [03:59] StevenK: Why not? [03:59] It was added just for garbo [03:59] And now garbo is gone [03:59] It was not. [03:59] Wasn't it? [03:59] You should read switch-bmp-to-previewdiff-merge_proposal carefully. [04:00] Ah, so you're leaving it for a reference that only appears in a later branch? [04:00] Pretty much [04:00] That's OK, then. [04:00] We really can't use it in the code until it's populated [04:00] 371 + @property [04:00] 372 def branch_merge_proposal(self): [04:00] Why does this still exist? [04:01] wgrant: Because it's exported :-( [04:01] StevenK: Hm, can you just call the property that, then? [04:01] Rather than having merge_proposal separate [04:01] Just call it branch_merge_proposal [04:02] So the merge_diff madness continues [04:02] Hm? [04:02] merge_proposal_id / branch_merge_proposal probably isn't going to make you like me [04:03] No, that's illegal. [04:03] Which means we have branch_merge_proposal = Int(name='merge_proposal') [04:03] Or you rename the DB column [04:03] This sort of thing is why you don't land DB patches early. Makes them easy to revise in context :) [04:04] * StevenK twitches at having to rename it in six branches [04:04] Well, five [04:17] StevenK: Also, have you considered pruning? [04:17] Until we have pruning, bmp.preview_diffs may grow without bound [04:18] I was thinking about that yesterday, but I'm not sure about the prune condition, since PreviewDiff.branch_merge_proposal is NOT NULL [04:18] We want to prune unreferenced ones. At the moment that probably just means everything except the latest. [04:18] But that will change once we start tying comments to a particular diff version [05:38] wgrant: Compound index? [05:42] StevenK: So we can efficiently answer "what is the current diff for this merge proposal?" [05:44] wgrant: Sure, I'm not sure what that index looks like, and if we need the current index in the patch [05:44] StevenK: (branch_merge_proposal, date_created) [05:45] (branch_merge_proposal) lets me quickly identify the diffs for the merge proposal, but without the additional sort of date_created I'd have to examine all of them to find the newest. [05:58] wgrant: how many diffs are you expecting to be attached to a MP? [05:59] If it is normally one or two and we never have thousands, I don't think the extra maintenance of the index is worth it. [06:00] stub: date_created will never change, and the index will always be appended to, so is that significant? [06:01] It should rarely be more than a dozen, but in pathological cases it may be. [06:01] And I don't see the expense of the additional index column as being particularly significant. [06:02] An extra index to keep hot, extra writes on insert, fatter index vs thin index and extra row loading... [06:02] And the overhead of all the extra typing in the db patch ;) [06:02] It's not an extra index, just a wider one. [06:03] oh right, new column. [06:03] We need one with branch_merge_proposal at the start either way [06:04] yup. I'm not fussed one way or t'other. === bigjools_ is now known as bigjools [06:05] If it were a larger table then I would be concerned about the wider index, but I don't think it's an issue here. === tasdomas_afk is now known as tasdomas === jamesh_ is now known as jamesh === broder_ is now known as broder [06:29] StevenK: https://code.launchpad.net/~wgrant/launchpad/dont-overrideFromAncestry/+merge/162933 [06:42] wgrant: r=me [06:42] StevenK: Thanks. [06:55] wgrant: Glance at the six again? === tasdomas is now known as tasdomas_afk === _mup__ is now known as _mup_ === jelmer_ is now known as jelmer === tasdomas_afk is now known as tasdomas === tasdomas is now known as tasdomas_afk === tasdomas_afk is now known as tasdomas === tasdomas is now known as tasdomas_afk === tasdomas_afk is now known as tasdomas === wedgwoodz is now known as wedgwood_away === tasdomas is now known as tasdomas_afk === wedgwood_away is now known as wedgwood === tasdomas_afk is now known as tasdomas === tasdomas is now known as tasdomas_afk === wedgwood is now known as wedgwood_away [23:42] wgrant: When you're done with , can you peer at the six MPs again? [23:45] StevenK: Sure