[11:54] <cjwatson> wgrant: "We only need to keep domain-specific methods on the Registry objects for API purposes" - do we even need that if we have a git_service or something like that that is itself exposed on the API, like sharing_service?
[11:55] <cjwatson> Creating all the infrastructure for a new service to avoid domain-specific registry methods only to add domain-specific shims to registry doesn't seem to gain an awful lot, but it would be more productive if we could avoid the shims altogether.
[11:58] <wgrant> cjwatson: Right, I mean more for historical reasons.
[11:58] <cjwatson> Oh, you mean the existing methods?  Right.
[11:59] <wgrant> If you don't hate the sharing_service style of exposing a set of related operations elsewhere, by all means do so.
[11:59] <wgrant> I don't think it's pretty, but I think it's a lot better than having every method for everything ever on Person and Product.
[11:59] <cjwatson> I'm not wild about it, I think it's potentially hard to find.
[11:59] <cjwatson> But as you say.
[11:59] <cjwatson> It might be good if we had a "see also" on apidoc.
[11:59] <wgrant> Indeed.
[12:00] <wgrant> Though for git it may be more sensible.
[12:01] <wgrant> Because the operations are more obviously interrelated.
[12:01] <wgrant> Git repositories have operations on them, but anything above the level of a git repository is on the single sharing service.
[12:02] <cjwatson> Yeah.  It'll take me a day or so to reorganise.
[12:02] <cjwatson> (But that's fine, I'd rather get it into roughly the right shape now.)
[12:03] <wgrant> Yeah, I think this should end up OK, and shouldn't be too huge a change at this stage.
[12:03] <wgrant> And if we can get an API that looks nice without being inside Registry, I'll be pretty pleased.
[12:04] <wgrant> I did fix lazr.restful last year to make Person a bit less unmanageable (adapters can add their own methods), but the apidoc still lists them all together, even if the interfaces and implementation are in a separate class.
[12:04] <wgrant> s/are/can be/
[12:05] <wgrant> That was more for splitting existing stuff out without breaking compat, though.
[12:30] <cjwatson> wgrant: Hm, so I think http://lpbuildbot.canonical.com/builders/lp-devel-precise/builds/346/steps/shell_9/logs/summary is all due to decorating Branch.recipes with preloading.  Would you prefer to allow branchscanner to see codeimport (which I can do in devel rather than db-devel, IIRC) or to pull the decoration up to BranchRecipeListingView?
[12:30] <cjwatson> Or something else I haven't thought of.
[12:32] <wgrant> cjwatson: I knew it'd break some DB perms, but that's an impressive set of failures.
[12:32] <wgrant> I'd just update security.cfg in devel
[12:32] <cjwatson> Maybe Branch could gain an undecorated equivalent of recipes just for use in bzrsync.
[12:33] <cjwatson> Since all it needs to do is set recipe.is_stale
[12:33] <wgrant> That's not a terrible idea, yeah.
[12:35] <cjwatson> Or even markRecipesStale or similar
[12:35] <cjwatson> Let's see
[12:50] <cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/recipe-timeouts/+merge/250913, if you're still alive?
[12:50] <cjwatson> All the failing/erroring tests now pass locally.
[12:51] <wgrant> Hmm.
[12:51] <wgrant> Not a huge fan, but it'll work and isn't objectively uglier than the other options.
[12:51] <cjwatson> Because of the extra method?
[12:52] <wgrant> Right.
[12:53] <cjwatson> I figured it was slightly better than leaving a potential performance bomb around for other users.
[13:29] <cjwatson> wgrant: Thinking about it, rather than adding a new service, why don't I just put these operations directly on GitRepositorySet?  I'm already planning to expose that as /git_repositories on the API, so that would be more economical.
[13:31] <cjwatson> And I already have a getDefaultRepository method there.
[13:31] <wgrant> True
[13:31] <wgrant> That works.
[13:32] <cjwatson> Indeed Product.getDefaultGitRepository calls it!  Not sure what I was thinking in not at least centralising the common code.
[13:32] <cjwatson> (in set)
[13:33] <cjwatson> It'll have to do its own permission checking, I suppose.
[13:34] <wgrant> SharingService has some precedent there.
[13:34] <wgrant> But some of those would have needed custom privilege checks anyway.
[13:38]  * wgrant sleeps.
[13:40] <cjwatson> night
[13:40] <cjwatson> thanks for the help
[21:05] <blr> wgrant: cjwatson: starting to think it might be useful to have a pygit2 fixture library of some sort - could provide a dict of the desired repo state, number of refs, branches, remotes, commits etc to build a pygit2.Repository object
[21:07] <blr> will push all of that into an api test helper, but might be useful to abstract it out further.
[22:38] <wgrant> Yeah, we'll definitely want something like that.
[23:18] <thomi> wgrant: first pass SS is https://launchpadlibrarian.net/198750892/Screenshot%20from%202015-02-26%2012%3A09%3A37.png
[23:18] <thomi> wgrant: I guess the 'add a new address' is why we need new authentication for +editemails?
[23:18] <wgrant> thomi: right, you need to reauthenticate to change your authentication information.
[23:19] <thomi> makes sense I guess :D
[23:19] <wgrant> Oh.
[23:19] <wgrant> So, I wouldn't break that convention there.
[23:20] <thomi> ugh - I just noticed I have it in two places in the SS
[23:20] <thomi> I meant to undo the one in the top line :D
[23:20] <wgrant> Every other item there is edited by the edit icon next to the title. I was thinking that there could be a "Subscribe to mailing lists" link or something like that.
[23:20] <wgrant> But making the edit link for email addresses inconsistent with the rest probably isn't a great idea.
[23:21] <thomi> OK. Do you think it's worth moving mailing list subs to a separate page?
[23:21] <thomi> then it could be linked form the right-hand box thingy... or beneath the email header
[23:23] <wgrant> I would split it into a separate page, yeah. You'll need to review internal links to +editemails (eg. subscribe/unsubscribe buttons on team pages), and add a link in the Emails section and on the existing +editemails page.
[23:27] <thomi> wgrant: ok... I'll take a look
[23:27] <thomi> I have no clue how to add another page, but... how hard can it be? :D
[23:27] <wgrant> thomi: Let me know when you have questions.
[23:27] <wgrant> Yep :)
[23:44] <thomi> wgrant: should clicking 'create mailing list' on a team when running launchpad.dev actually do something? or maybe the mailman backend is missing?
[23:44] <wgrant> thomi: initscript-start doesn't start it, but 'make run' should.
[23:44] <wgrant> IIRC
[23:44] <thomi> hmmm, that's what I'm using.
[23:45] <thomi> maybe I'm being impatient
[23:45] <thomi> I get "This team's mailing list will be available within a few minutes."
[23:45] <thomi> but I haven't actually waited a few minutes
[23:48] <wgrant> thomi: Oh, run doesn't include mailman any more, that's right.
[23:48] <wgrant> Try run_all
[23:49] <wgrant> You can see what runs mailman in Makefile
[23:49] <thomi> ahh
[23:50] <thomi> much better - now I get an oops instead of a blank widget :D
[23:51] <wgrant> Heh
[23:53] <thomi> sweet - got a separate page rendered correctly. time for lunch
[23:53] <wgrant> :)