[11:54] 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] 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] cjwatson: Right, I mean more for historical reasons. [11:58] Oh, you mean the existing methods? Right. [11:59] If you don't hate the sharing_service style of exposing a set of related operations elsewhere, by all means do so. [11:59] 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] I'm not wild about it, I think it's potentially hard to find. [11:59] But as you say. [11:59] It might be good if we had a "see also" on apidoc. [11:59] Indeed. [12:00] Though for git it may be more sensible. [12:01] Because the operations are more obviously interrelated. [12:01] Git repositories have operations on them, but anything above the level of a git repository is on the single sharing service. [12:02] Yeah. It'll take me a day or so to reorganise. [12:02] (But that's fine, I'd rather get it into roughly the right shape now.) [12:03] Yeah, I think this should end up OK, and shouldn't be too huge a change at this stage. [12:03] And if we can get an API that looks nice without being inside Registry, I'll be pretty pleased. [12:04] 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] s/are/can be/ [12:05] That was more for splitting existing stuff out without breaking compat, though. [12:30] 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] Or something else I haven't thought of. [12:32] cjwatson: I knew it'd break some DB perms, but that's an impressive set of failures. [12:32] I'd just update security.cfg in devel [12:32] Maybe Branch could gain an undecorated equivalent of recipes just for use in bzrsync. [12:33] Since all it needs to do is set recipe.is_stale [12:33] That's not a terrible idea, yeah. [12:35] Or even markRecipesStale or similar [12:35] Let's see [12:50] wgrant: https://code.launchpad.net/~cjwatson/launchpad/recipe-timeouts/+merge/250913, if you're still alive? [12:50] All the failing/erroring tests now pass locally. [12:51] Hmm. [12:51] Not a huge fan, but it'll work and isn't objectively uglier than the other options. [12:51] Because of the extra method? [12:52] Right. [12:53] I figured it was slightly better than leaving a potential performance bomb around for other users. [13:29] 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] And I already have a getDefaultRepository method there. [13:31] True [13:31] That works. [13:32] Indeed Product.getDefaultGitRepository calls it! Not sure what I was thinking in not at least centralising the common code. [13:32] (in set) [13:33] It'll have to do its own permission checking, I suppose. [13:34] SharingService has some precedent there. [13:34] But some of those would have needed custom privilege checks anyway. [13:38] * wgrant sleeps. [13:40] night [13:40] thanks for the help [21:05] 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] will push all of that into an api test helper, but might be useful to abstract it out further. [22:38] Yeah, we'll definitely want something like that. [23:18] wgrant: first pass SS is https://launchpadlibrarian.net/198750892/Screenshot%20from%202015-02-26%2012%3A09%3A37.png [23:18] wgrant: I guess the 'add a new address' is why we need new authentication for +editemails? [23:18] thomi: right, you need to reauthenticate to change your authentication information. [23:19] makes sense I guess :D [23:19] Oh. [23:19] So, I wouldn't break that convention there. [23:20] ugh - I just noticed I have it in two places in the SS [23:20] I meant to undo the one in the top line :D [23:20] 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] But making the edit link for email addresses inconsistent with the rest probably isn't a great idea. [23:21] OK. Do you think it's worth moving mailing list subs to a separate page? [23:21] then it could be linked form the right-hand box thingy... or beneath the email header [23:23] 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] wgrant: ok... I'll take a look [23:27] I have no clue how to add another page, but... how hard can it be? :D [23:27] thomi: Let me know when you have questions. [23:27] Yep :) [23:44] 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] thomi: initscript-start doesn't start it, but 'make run' should. [23:44] IIRC [23:44] hmmm, that's what I'm using. [23:45] maybe I'm being impatient [23:45] I get "This team's mailing list will be available within a few minutes." [23:45] but I haven't actually waited a few minutes [23:48] thomi: Oh, run doesn't include mailman any more, that's right. [23:48] Try run_all [23:49] You can see what runs mailman in Makefile [23:49] ahh [23:50] much better - now I get an oops instead of a blank widget :D [23:51] Heh [23:53] sweet - got a separate page rendered correctly. time for lunch [23:53] :)