| cjwatson | 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:42 |
|---|---|---|
| rpadovani | \o/ | 09:49 |
| cjwatson | wgrant: For the AccessArtifact index changes, is there a reasonable way to test performance? Maybe timings on dogfood? | 12:15 |
| cjwatson | (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:15 |
| wgrant | cjwatson: Sure, postgres DDL is fully transactional. | 12:19 |
| wgrant | 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:20 |
| cjwatson | So I just do BEGIN / blah / ROLLBACK? | 12:21 |
| wgrant | Dogfood is good for timing, yep | 12:21 |
| cjwatson | Is DDL timing within a transaction reasonably reliable? I mean it doesn't just defer most of the work until commit? | 12:22 |
| wgrant | COMMIT is by necessity instantaneous. | 12:22 |
| cjwatson | 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 |
| wgrant | Well, that's true, it won't fsync before the COMMIT. | 12:23 |
| wgrant | (or do synchronous commit) | 12:24 |
| wgrant | But the vast majority of the work is done before the COMMIT. | 12:24 |
| cjwatson | Oh, and how would you recommend getting an accurate timing? | 12:25 |
| wgrant | \timing on | 12:25 |
| cjwatson | Thanks | 12:25 |
| cjwatson | wgrant: Timings in the MP now | 12:30 |
| cjwatson | https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess suggests that 1.5 seconds may be tolerable? | 12:32 |
| wgrant | I guess AccessArtifact is only private stuff, so if it's hot it should be easy. | 12:32 |
| wgrant | We need to ensure it's hot beforehand, though; wildcherry is crap. | 12:33 |
| cjwatson | 224143 rows on DF | 12:33 |
| wgrant | That could well be fine. They're narrower rows than I'd remembered. | 12:34 |
| wgrant | cjwatson: Speaking of which, when is your meeting preference this week? | 12:34 |
| cjwatson | 8MB | 12:34 |
| cjwatson | (table size) | 12:35 |
| wgrant | Yeah, the rows are basic two ints + header each. | 12:35 |
| cjwatson | wgrant: Either day is workable, but I think Tuesday as in the calendar is best. | 12:35 |
| wgrant | Sounds good. | 12:35 |
| wgrant | Easier than working out how to move an event in Google Calendar. | 12:35 |
| cjwatson | :-) | 12:36 |
| cjwatson | 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:36 |
| wgrant | I knew there was something I was missing, yeah. | 12:37 |
| wgrant | We probably want two separate flags to make the unique constraints and queries more sensible. | 12:37 |
| wgrant | Though an enum wouldn't be terrible, I'm not sure it's worth it. | 12:37 |
| cjwatson | 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 |
| cjwatson | (or s/official/preferred/g or s/official/default/g, something like that) | 12:40 |
| wgrant | Yep, exactly. | 12:40 |
| wgrant | Then the unique indices and queries are trivial. | 12:40 |
| cjwatson | Gets rid of a lot of duplication in the GitShortcut definition, certainly. | 12:41 |
| cjwatson | Might need a little bit of care in personmerge. | 12:42 |
| wgrant | Yeah, but branches are already handled specially anyway due to name conflicts. | 12:42 |
| wgrant | I'd assume that the default flags get unset upon move. | 12:42 |
| cjwatson | If there's a conflict, at least, eys. | 12:42 |
| cjwatson | *yes | 12:42 |
| wgrant | target_default has to be unset regardless, but owner_default could stay if it doesn't conflict, yeah. | 12:43 |
| cjwatson | Why does target_default have to be unset if there's no conflict? | 12:43 |
| cjwatson | Just changing the owner around shouldn't matter for that. | 12:44 |
| wgrant | I guess if it's just the owner changing, true. | 12:44 |
| cjwatson | target_default probably ought to be unset if you're changing the target, granted. | 12:44 |
| wgrant | Yeah, you're right, I'd forgotten that changing the user counted as a move. | 12:45 |
| cjwatson | I think owner_default OR NOT target_default would make a better constraint, actually. | 13:00 |
| cjwatson | We don't want to have launchpad-pqm be the owner of launchpad and to have lp:~launchpad-pqm/launchpad != lp:launchpad. | 13:01 |
| cjwatson | So if target_default is true then owner_default must also be true, to avoid silliness. | 13:02 |
| wgrant | Yeah, indeed. | 13:12 |
| wgrant | cjwatson: You have enough to go on now? | 13:12 |
| wgrant | 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:13 |
| cjwatson | I think so. I'm not sure how to avoid that either, I've been going back and forward on None vs. IPerson. | 13:15 |
| cjwatson | 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:17 |
| cjwatson | 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 |
| wgrant | Yeah | 13:18 |
| cjwatson | But the downside there is that it makes the webservice implementation less obvious. | 13:18 |
| wgrant | What would the non-None target be? | 13:18 |
| cjwatson | PersonalGitTarget(owner=foo) | 13:18 |
| wgrant | Ah | 13:18 |
| cjwatson | Or whatever | 13:18 |
| wgrant | But yeah, that makes the webservice impossible. | 13:18 |
| wgrant | 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 |
| cjwatson | We'd have to go back to project= distro_source_package=, or else export IGitTarget on the webservice. Neither is very palatable. | 13:19 |
| wgrant | But personal bugs aren't a thing. | 13:19 |
| cjwatson | So I think target=owner for those is the least bad alternative. | 13:19 |
| wgrant | I agree. | 13:19 |
| wgrant | Oh, it's IS meeting week. I'd best sleep. | 13:30 |
| cjwatson | night | 13:30 |
| rpadovani | cjwatson, o/ Do you have ever thougth to apply Launchpad to Google Summer of Code? :-) | 19:59 |
| cjwatson | rpadovani: I've only been full-time on LP for a month, give me a chance :-) | 20:21 |
| cjwatson | I don't know that kind of history | 20:22 |
| jelmer | IIRC there was one year in which we had joint Bazaar/Launchpad participation in the SoC | 22:29 |
| wgrant | I don't recall Launchpad ever doing it, but Bazaar may have. | 22:38 |
| jelmer | wgrant: Yeah, you're right | 22:44 |
| jelmer | https://developers.google.com/open-source/soc/2007/#bzr | 22:44 |
| jelmer | I think what I must be remembering is that Bazaar once participated under the umbrella of Ubuntu | 22:44 |
| wgrant | Ah yes, that sounds plausible. | 22:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!