| 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:54 |
|---|---|---|
| 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:55 |
| wgrant | cjwatson: Right, I mean more for historical reasons. | 11:58 |
| cjwatson | Oh, you mean the existing methods? Right. | 11:58 |
| 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. | 11:59 |
| wgrant | Though for git it may be more sensible. | 12:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| wgrant | That was more for splitting existing stuff out without breaking compat, though. | 12:05 |
| 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:30 |
| 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:32 |
| cjwatson | Since all it needs to do is set recipe.is_stale | 12:33 |
| wgrant | That's not a terrible idea, yeah. | 12:33 |
| cjwatson | Or even markRecipesStale or similar | 12:35 |
| cjwatson | Let's see | 12:35 |
| 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:50 |
| 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:51 |
| wgrant | Right. | 12:52 |
| cjwatson | I figured it was slightly better than leaving a potential performance bomb around for other users. | 12:53 |
| 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:29 |
| cjwatson | And I already have a getDefaultRepository method there. | 13:31 |
| wgrant | True | 13:31 |
| wgrant | That works. | 13:31 |
| 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:32 |
| cjwatson | It'll have to do its own permission checking, I suppose. | 13:33 |
| wgrant | SharingService has some precedent there. | 13:34 |
| wgrant | But some of those would have needed custom privilege checks anyway. | 13:34 |
| * wgrant sleeps. | 13:38 | |
| cjwatson | night | 13:40 |
| cjwatson | thanks for the help | 13:40 |
| 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:05 |
| blr | will push all of that into an api test helper, but might be useful to abstract it out further. | 21:07 |
| wgrant | Yeah, we'll definitely want something like that. | 22:38 |
| 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:18 |
| thomi | makes sense I guess :D | 23:19 |
| wgrant | Oh. | 23:19 |
| wgrant | So, I wouldn't break that convention there. | 23:19 |
| 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:20 |
| 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:21 |
| 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:23 |
| 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:27 |
| 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:44 |
| 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:45 |
| wgrant | thomi: Oh, run doesn't include mailman any more, that's right. | 23:48 |
| wgrant | Try run_all | 23:48 |
| wgrant | You can see what runs mailman in Makefile | 23:49 |
| thomi | ahh | 23:49 |
| thomi | much better - now I get an oops instead of a blank widget :D | 23:50 |
| wgrant | Heh | 23:51 |
| thomi | sweet - got a separate page rendered correctly. time for lunch | 23:53 |
| wgrant | :) | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
