[00:30] cjwatson: The comment is misleading (it skips whole sources, not single templates), but other than that it looks good. [05:43] wgrant: was just going to make an mp for the squid-forwardproxy settings, but noted your branch is still for precise, worth renaming to charms/trusty/squid-forwardproxy? [05:45] blr: There's no trusty charm branch today, and there's no need for the charm to differ between series, so we might as well keep it in precise for now. [05:45] AFAIK the Ecosystem people don't have good policies for sharing charms between series. [05:50] wgrant: okay fair enough, no issue deploying it to trusty at any rate, it was more cosmetic. [08:30] wgrant: Working on tests for it and struggling to see how this makes sense ... http://paste.ubuntu.com/12012366/ [08:31] it just dropped that table, how can it already exist? [08:32] cjwatson: hee hee [08:32] cjwatson: Check the postgres log for the query that failed, but I think you'll find it's an amusing and confusing truncation bug. [08:32] Relation names are limited. [08:33] The query is creating an index called temp_translationtemplateitem_holding_distribution-100000_target_id, but the last three characters are too long, so it gets truncated to what happens to be the same name as the table. [08:33] argh [08:33] >>> len('temp_translationtemplateitem_holding_distribution-100000_target') [08:33] 63 [08:34] hatred [08:34] all right, makeDistribution(name='short') it is [08:34] Let's just hope we don't need ubuntu-rtm-seriously-this-is-the-last-fork-never-again-i-swear. [08:35] oh and indeed there's a comment in another test about that [08:35] Heh, is there? [08:35] Ah. [08:36] That might be why I knew it immediately, I added that comment in August last year. [10:44] wgrant: https://code.launchpad.net/~cjwatson/launchpad/send-bug-notifications-oops/+merge/264814, the actual notification that generated the message being sent is ... well, it's available somewhere, but construct_email_notifications loses the mapping pretty thoroughly. Is it worth the hassle to fix that, or should I just do something like dumping out the IDs of all notifications in the current batch? [10:49] cjwatson: Ah, right, the loop references *a* BugNotification, but it's not exactly the relevant one. Carry on, then. [10:49] OK :) [13:17] wgrant: Trying to think of where to put the +new-snap view. It could go on /+snaps/+new-snap, but then I don't see how anyone would be able to find it. It could go on /+new-snap, which seems better in that it's discoverable and would save having to put a branch/ref picker on the +new-snap page. But then I'd kind of want an IHasSnaps to attach the browser:page tag to, and you just asked me to remove that from an ... [13:17] ... earlier branch :-) [13:18] (And you just attached webhooks to repositories in a reasonably similar way ...) [13:19] cjwatson: A webhook is strictly subordinate to a git repository, and is managed by the people who manage the repository. It is basically an extension of the repository's configuration. [13:19] IHasSnaps doesn't have to die, but I think the API-accessible collection on the branch/repo should. [13:19] It's a relationship which crosses application domains and has no clear hierarchy. [13:20] I am loathe to clutter up branch and git repo pages with snap bits (think how useless the recipe is on most of them), but I'm not sure how better to do it. [13:21] Right, I'm not suggesting bringing back the webservice collection. [13:22] Snaps themselves are currently subordinate only to their owner. I suppose they could be discoverable just by putting a link on Person:+index, but that seems little better in terms of clutter, and still leaves the picker issue. [13:22] (And Person:+index is already massive) [13:22] IMO private interfaces may violate layering if it is significantly beneficial, but public APIs should not as they're very difficult to change later. [13:23] Indeed. [13:23] Branch:+index is also fairly large but it's also already mostly useless. [13:23] So I think cross-linking is a bit different from subordinate relationships. [13:23] So adding another useless link is probably not a big problem. [13:23] i.e. having Branch:+new-snap doesn't mean that the resulting object is subordinate to Branch [13:24] Oh sure, I think that might be the most reasonable path forward. [13:25] The other possibility I can think of is a link on Branch:+index to /+snaps/+new-snap?branch=foo, but that seems like complication for little benefit. [13:25] The snap source might as well be the context object there. [13:27] Right, adding a new view under Branch isn't a serious problem. [13:27] Cluttered view namespaces aren't an issue. [13:27] Cluttered API namespaces are permanent. [13:27] Yep. [13:27] Cluttered UI is annoying. [13:28] Perhaps we can minimise the clutter by renaming the "Related source package recipes" section somehow and putting the +new-snap link in there. [13:28] Indeed, I think that makes sense. [13:28] They're not dissimilar. [13:28] They are very similar indeed. [13:29] (Maybe I should have put Snap* under code ...) [13:29] OTOH a branch/repo picker really wouldn't be that bad. [13:29] Meh, lib/lp isn't too cluttered. [13:29] lib/lp/services is. [13:29] This is always going to be a pretty separate component. [13:29] No, but I don't think it really makes sense. You have a branch and you want to make a snap package out of it. [13:29] It is more closely tied to buildmaster than it is code. [13:30] That is true, but in most cases you have a branch and you *don't* want to make a snap package out of it. [13:30] Reworking the Branch:+index recipes section is consistent with what we have done previously, and it is probably what we should do here. [13:30] Mm, still leaves the discoverability question though. [13:31] But "X (where X is 0.1% of the population) want to Y from Z, therefore Z must prominently show Y" is how the UI got into this state, so I like to think up ways to avoid it in future. [13:31] (If it's not linked to from branch/ref, that is; and if it is linked to from there then there's no reason not to fill in the context.) [13:31] Right. [13:31] Part of the problem is a paucity of alternatives for things that are otherwise quite isolated. [13:31] Exactly the issue. [13:32] livefs we could get away with being largely undiscoverable because only a dozen people care. [13:32] There may also be the argument that building a snap in isolation on LP is a relatively rare case, and that the workflow would mostly be entered from external services. [13:32] I don't know if that's a reasonable assumption. [13:34] Perhaps /+code-imports/+new is interesting precedent too. [13:34] The only links to it are external (e.g. help.l.n) and the weird big green link button from the top of code. [13:35] It is also a rarely used page. [13:35] https://code.launchpad.net/launchpad/+new-import is more common. [13:37] That sort of points towards /+new-snap without a picker rather than /+snaps/+new with [13:38] All precedent undoubtedly points to that, indeed. [13:39] Maybe I'm wrong in looking for precedent :-) [13:39] I could also just do /+snaps/+new with a picker on the grounds that it's easy to add /+new without a picker later [13:39] Er /+new-snap [13:40] * cjwatson argues self into knots [13:56] cjwatson: Any revelations? [13:58] I'm quite tempted to do both in the way we do for new code imports. :-P The one with a context object would be behind a feature flag anyway for some time ... [13:59] But I can see developer.ubuntu.com usefully linking to /+snaps/+new [13:59] (e.g.) [13:59] Right. [13:59] I'm not sure it necessarily makes sense to have a separate $CONTEXT/+new-snap rather than the link just prefilling the field on /+snaps/+new, but we can try. [14:00] Can certainly try that. [20:33] morning