wgrantcjwatson: The comment is misleading (it skips whole sources, not single templates), but other than that it looks good.00:30
blrwgrant: 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:43
wgrantblr: 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
wgrantAFAIK the Ecosystem people don't have good policies for sharing charms between series.05:45
blrwgrant: okay fair enough, no issue deploying it to trusty at any rate, it was more cosmetic.05:50
cjwatsonwgrant: Working on tests for it and struggling to see how this makes sense ... http://paste.ubuntu.com/12012366/08:30
cjwatsonit just dropped that table, how can it already exist?08:31
wgrantcjwatson: hee hee08:32
wgrantcjwatson: 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
wgrantRelation names are limited.08:32
wgrantThe 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
wgrant>>> len('temp_translationtemplateitem_holding_distribution-100000_target')08:33
cjwatsonall right, makeDistribution(name='short') it is08:34
wgrantLet's just hope we don't need ubuntu-rtm-seriously-this-is-the-last-fork-never-again-i-swear.08:34
cjwatsonoh and indeed there's a comment in another test about that08:35
wgrantHeh, is there?08:35
wgrantThat might be why I knew it immediately, I added that comment in August last year.08:36
cjwatsonwgrant: 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:44
wgrantcjwatson: Ah, right, the loop references *a* BugNotification, but it's not exactly the relevant one. Carry on, then.10:49
cjwatsonOK :)10:49
cjwatsonwgrant: 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 <branch or ref>/+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
cjwatson... earlier branch :-)13:17
cjwatson(And you just attached webhooks to repositories in a reasonably similar way ...)13:18
wgrantcjwatson: 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
wgrantIHasSnaps doesn't have to die, but I think the API-accessible collection on the branch/repo should.13:19
wgrantIt's a relationship which crosses application domains and has no clear hierarchy.13:19
wgrantI 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:20
cjwatsonRight, I'm not suggesting bringing back the webservice collection.13:21
cjwatsonSnaps 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
cjwatson(And Person:+index is already massive)13:22
wgrantIMO private interfaces may violate layering if it is significantly beneficial, but public APIs should not as they're very difficult to change later.13:22
wgrantBranch:+index is also fairly large but it's also already mostly useless.13:23
cjwatsonSo I think cross-linking is a bit different from subordinate relationships.13:23
wgrantSo adding another useless link is probably not a big problem.13:23
cjwatsoni.e. having Branch:+new-snap doesn't mean that the resulting object is subordinate to Branch13:23
wgrantOh sure, I think that might be the most reasonable path forward.13:24
cjwatsonThe 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
cjwatsonThe snap source might as well be the context object there.13:25
wgrantRight, adding a new view under Branch isn't a serious problem.13:27
wgrantCluttered view namespaces aren't an issue.13:27
wgrantCluttered API namespaces are permanent.13:27
wgrantCluttered UI is annoying.13:27
cjwatsonPerhaps we can minimise the clutter by renaming the "Related source package recipes" section somehow and putting the +new-snap link in there.13:28
wgrantIndeed, I think that makes sense.13:28
cjwatsonThey're not dissimilar.13:28
wgrantThey are very similar indeed.13:28
cjwatson(Maybe I should have put Snap* under code ...)13:29
wgrantOTOH a branch/repo picker really wouldn't be that bad.13:29
wgrantMeh, lib/lp isn't too cluttered.13:29
wgrantlib/lp/services is.13:29
wgrantThis is always going to be a pretty separate component.13:29
cjwatsonNo, 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
wgrantIt is more closely tied to buildmaster than it is code.13:29
wgrantThat 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
wgrantReworking the Branch:+index recipes section is consistent with what we have done previously, and it is probably what we should do here.13:30
cjwatsonMm, still leaves the discoverability question though.13:30
wgrantBut "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
cjwatson(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
cjwatsonPart of the problem is a paucity of alternatives for things that are otherwise quite isolated.13:31
wgrantExactly the issue.13:31
cjwatsonlivefs we could get away with being largely undiscoverable because only a dozen people care.13:32
wgrantThere 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
wgrantI don't know if that's a reasonable assumption.13:32
cjwatsonPerhaps /+code-imports/+new is interesting precedent too.13:34
cjwatsonThe only links to it are external (e.g. help.l.n) and the weird big green link button from the top of code.13:34
wgrantIt is also a rarely used page.13:35
wgranthttps://code.launchpad.net/launchpad/+new-import is more common.13:35
cjwatsonThat sort of points towards <context>/+new-snap without a picker rather than /+snaps/+new with13:37
wgrantAll precedent undoubtedly points to that, indeed.13:38
cjwatsonMaybe I'm wrong in looking for precedent :-)13:39
cjwatsonI could also just do /+snaps/+new with a picker on the grounds that it's easy to add <context>/+new without a picker later13:39
cjwatsonEr <context>/+new-snap13:39
* cjwatson argues self into knots13:40
wgrantcjwatson: Any revelations?13:56
cjwatsonI'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:58
cjwatsonBut I can see developer.ubuntu.com usefully linking to /+snaps/+new13:59
wgrantI'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.13:59
cjwatsonCan certainly try that.14:00

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!