[09:42] <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:49] <rpadovani> \o/
[12:15] <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:19] <wgrant> cjwatson: Sure, postgres DDL is fully transactional.
[12:20] <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:21] <cjwatson> So I just do BEGIN / blah / ROLLBACK?
[12:21] <wgrant> Dogfood is good for timing, yep
[12:22] <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:23] <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:24] <wgrant> (or do synchronous commit)
[12:24] <wgrant> But the vast majority of the work is done before the COMMIT.
[12:25] <cjwatson> Oh, and how would you recommend getting an accurate timing?
[12:25] <wgrant> \timing on
[12:25] <cjwatson> Thanks
[12:30] <cjwatson> wgrant: Timings in the MP now
[12:32] <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:33] <wgrant> We need to ensure it's hot beforehand, though; wildcherry is crap.
[12:33] <cjwatson> 224143 rows on DF
[12:34] <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:35] <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:36] <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:37] <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:40] <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:41] <cjwatson> Gets rid of a lot of duplication in the GitShortcut definition, certainly.
[12:42] <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:43] <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:44] <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:45] <wgrant> Yeah, you're right, I'd forgotten that changing the user counted as a move.
[13:00] <cjwatson> I think  owner_default OR NOT target_default  would make a better constraint, actually.
[13:01] <cjwatson> We don't want to have launchpad-pqm be the owner of launchpad and to have lp:~launchpad-pqm/launchpad != lp:launchpad.
[13:02] <cjwatson> So if target_default is true then owner_default must also be true, to avoid silliness.
[13:12] <wgrant> Yeah, indeed.
[13:12] <wgrant> cjwatson: You have enough to go on now?
[13:13] <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:15] <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:17] <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:18] <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:19] <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:30] <wgrant> Oh, it's IS meeting week. I'd best sleep.
[13:30] <cjwatson> night
[19:59] <rpadovani> cjwatson, o/ Do you have ever thougth to apply Launchpad to Google Summer of Code? :-)
[20:21] <cjwatson> rpadovani: I've only been full-time on LP for a month, give me a chance :-)
[20:22] <cjwatson> I don't know that kind of history
[22:29] <jelmer> IIRC there was one year in which we had joint Bazaar/Launchpad participation in the SoC
[22:38] <wgrant> I don't recall Launchpad ever doing it, but Bazaar may have.
[22:44] <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:51] <wgrant> Ah yes, that sounds plausible.