[09:42] rpadovani: Heh, I wondered when somebody would notice. Not quite ready to give a timeline yet but we're working pretty hard on it [09:49] \o/ [12:15] wgrant: For the AccessArtifact index changes, is there a reasonable way to test performance? Maybe timings on dogfood? [12:15] (And is it possible to test this kind of schema change in something transaction-like, so that I'm not actually mutating the live schema?) [12:19] cjwatson: Sure, postgres DDL is fully transactional. [12:20] I've realised that my NOT VALID suggestion won't work directly, though, since the lock reductions got reverted. But we can easily hack the catalog if it's too slow. [12:21] So I just do BEGIN / blah / ROLLBACK? [12:21] Dogfood is good for timing, yep [12:22] Is DDL timing within a transaction reasonably reliable? I mean it doesn't just defer most of the work until commit? [12:22] COMMIT is by necessity instantaneous. [12:23] http://www.postgresql.org/docs/9.3/static/sql-begin.html has an admonition about statements being executed more quickly inside a transaction [12:23] Well, that's true, it won't fsync before the COMMIT. [12:24] (or do synchronous commit) [12:24] But the vast majority of the work is done before the COMMIT. [12:25] Oh, and how would you recommend getting an accurate timing? [12:25] \timing on [12:25] Thanks [12:30] wgrant: Timings in the MP now [12:32] https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess suggests that 1.5 seconds may be tolerable? [12:32] I guess AccessArtifact is only private stuff, so if it's hot it should be easy. [12:33] We need to ensure it's hot beforehand, though; wildcherry is crap. [12:33] 224143 rows on DF [12:34] That could well be fine. They're narrower rows than I'd remembered. [12:34] cjwatson: Speaking of which, when is your meeting preference this week? [12:34] 8MB [12:35] (table size) [12:35] Yeah, the rows are basic two ints + header each. [12:35] wgrant: Either day is workable, but I think Tuesday as in the calendar is best. [12:35] Sounds good. [12:35] Easier than working out how to move an event in Google Calendar. [12:36] :-) [12:36] I think the only unaddressed bit of the db-git review is the flag/shortcut question. If the enum approach sounds workable I can try implementing that today. [12:37] I knew there was something I was missing, yeah. [12:37] We probably want two separate flags to make the unique constraints and queries more sensible. [12:37] Though an enum wouldn't be terrible, I'm not sure it's worth it. [12:40] So owner_official boolean NOT NULL, official boolean NOT NULL, CONSTRAINT blah CHECK (NOT owner_official OR NOT official); owner_official true implies lp:~cjwatson/launchpad, official true implies lp:launchpad, both false implies unofficial repo [12:40] (or s/official/preferred/g or s/official/default/g, something like that) [12:40] Yep, exactly. [12:40] Then the unique indices and queries are trivial. [12:41] Gets rid of a lot of duplication in the GitShortcut definition, certainly. [12:42] Might need a little bit of care in personmerge. [12:42] Yeah, but branches are already handled specially anyway due to name conflicts. [12:42] I'd assume that the default flags get unset upon move. [12:42] If there's a conflict, at least, eys. [12:42] *yes [12:43] target_default has to be unset regardless, but owner_default could stay if it doesn't conflict, yeah. [12:43] Why does target_default have to be unset if there's no conflict? [12:44] Just changing the owner around shouldn't matter for that. [12:44] I guess if it's just the owner changing, true. [12:44] target_default probably ought to be unset if you're changing the target, granted. [12:45] Yeah, you're right, I'd forgotten that changing the user counted as a move. [13:00] I think owner_default OR NOT target_default would make a better constraint, actually. [13:01] We don't want to have launchpad-pqm be the owner of launchpad and to have lp:~launchpad-pqm/launchpad != lp:launchpad. [13:02] So if target_default is true then owner_default must also be true, to avoid silliness. [13:12] Yeah, indeed. [13:12] cjwatson: You have enough to go on now? [13:13] The only niggle I have with the model now is the owner == target duplication, but I don't think we can sensibly avoid it completely. [13:15] I think so. I'm not sure how to avoid that either, I've been going back and forward on None vs. IPerson. [13:17] target=None is more Branch-like, and the root of why it's coming up now is that I've simplified away the various places where we pass separate project and sourcepackage arguments there to a single target. [13:18] Should I introduce IGitTarget? That's the one major piece of the Branch* cluster that I was able to omit, but if I introduced that then I could pass a non-None target for personal repositories. [13:18] Yeah [13:18] But the downside there is that it makes the webservice implementation less obvious. [13:18] What would the non-None target be? [13:18] PersonalGitTarget(owner=foo) [13:18] Ah [13:18] Or whatever [13:18] But yeah, that makes the webservice impossible. [13:19] Simplifying everything to take a single abstract target= is definitely the right way to go. I took Bugs most of the way in 2012, and it worked fine. [13:19] We'd have to go back to project= distro_source_package=, or else export IGitTarget on the webservice. Neither is very palatable. [13:19] But personal bugs aren't a thing. [13:19] So I think target=owner for those is the least bad alternative. [13:19] I agree. [13:30] Oh, it's IS meeting week. I'd best sleep. [13:30] night [19:59] cjwatson, o/ Do you have ever thougth to apply Launchpad to Google Summer of Code? :-) [20:21] rpadovani: I've only been full-time on LP for a month, give me a chance :-) [20:22] I don't know that kind of history [22:29] IIRC there was one year in which we had joint Bazaar/Launchpad participation in the SoC [22:38] I don't recall Launchpad ever doing it, but Bazaar may have. [22:44] wgrant: Yeah, you're right [22:44] https://developers.google.com/open-source/soc/2007/#bzr [22:44] I think what I must be remembering is that Bazaar once participated under the umbrella of Ubuntu [22:51] Ah yes, that sounds plausible.