[09:55] <wgrant> cjwatson: Can you merge up snap-add-view?
[09:56] <cjwatson> Oh, right, that actually needs a not entirely trivial merge due to the ZPT macrology
[09:56] <wgrant> Yup
[09:57] <wgrant> Not hugely difficult, fortunately.
[09:57] <cjwatson> Would you be inclined to use a slot or a variable for the create_snap link there?
[09:57] <cjwatson> Since gitrepository isn't going to get it
[09:58] <wgrant> I think that makes sense as a variable.
[09:58] <wgrant> If it works.
[09:58] <wgrant> I always have to look up exactly how macros work.
[09:58] <wgrant> Normally I just cargo-cult...
[09:59] <cjwatson> Yeah
[09:59] <cjwatson> I can't find the order of evaluation of tal:define vs. metal:use-macro defined anywhere
[10:03] <cjwatson> Oh, or I could just include the link if context_menu/create_snap exists, no need for a variable
[10:05] <wgrant> Did you having a a single generic add view, with the link from Code just populating the source field?
[10:06] <wgrant> I'm happy either way.
[10:06] <wgrant> Bah, edit lag
[10:06] <wgrant> s/having a a/consider having a/
[10:06] <cjwatson> That's what I have, right?
[10:07] <wgrant> You have a single view class, but it acts as a view on the source object.
[10:07] <wgrant> Rather than the branches linking into the snappy hierarchy, there is this single parasite.
[10:08] <wgrant> Well, I guess also the listing views, and they're more awkward to move.
[10:08] <wgrant> So carry on.
[10:08] <cjwatson> I did originally have something like /+snaps/+new, but thought it was simpler to use the context rather than passing variables around
[10:08] <cjwatson> I can try again if you think it might be worthwhile
[10:09] <wgrant> Not much point while +snaps is adjacent.
[10:23] <wgrant> Right, so I think I have reasonably good xref ports locally, though I may need to create fake BugTags for search performance
[10:23] <wgrant> (QuestionBug, BugBranch, SpecificationBug, SpecificationBranch abolished)
[10:24] <cjwatson> Nice
[10:24] <cjwatson> wgrant: snap-add-view pushed
[10:24] <wgrant> Thanks, looking.
[10:25] <wgrant> Hm, if I do fake tags then I can kill BugCve too.
[10:25] <cjwatson> I guess create_snap could go in HasSnapsMenuMixin, maybe?  Would need logic to exclude GitRepository until I make +new-snap smarter
[10:26] <wgrant> GitRepositoryNavigationMenu could just set create_snap to None
[10:26] <cjwatson> ContextMenu but yeah
[10:26] <wgrant> Er that
[10:26] <wgrant> I don't remember the difference.
[10:26] <cjwatson> Yeah, OK, let's do that
[10:28] <wgrant> Also I think it's "snappy Ubuntu Core", though I might be out of date.
[10:28] <wgrant> The ubuntu.com page sneakily only uses it at the start of a sentence.
[10:29] <wgrant> Ah no, "Try snappy Ubuntu Core"
[10:29] <cjwatson> I'll ask #snappy-internal
[10:30] <wgrant> A critical issue, I know.
[10:30] <wgrant> And snapcraft seems consistently lowercase.
[10:34] <cjwatson> Nobody has any taste, but oh well.
[10:34] <wgrant> Heh, quite.
[10:34] <cjwatson> (Actually, I'm OK with snapcraft if it's being treated as a Unix utility.)
[10:35] <wgrant> Not as distasteful but unavoidable as BuildableDistroSeries, fortunately.
[10:35] <wgrant> The snapcraft docs use "Snapcraft" at the start of a sentence, and snapcraft both monospaced and not.
[10:35] <wgrant> So even the non-command version should be lowercase.
[10:36] <wgrant> cjwatson: Do you deliberately exclude SUPPORTED series?
[10:36] <wgrant> Like, say, trusty.
[10:36] <wgrant> Or rather lts+1, I guess
[10:36] <wgrant> Since trusty is too old.
[10:37] <wgrant> lgtm otherwise
[10:49] <cjwatson> wgrant: so that's confusing because this is not the observed behaviour
[10:49] <cjwatson> trusty is SUPPORTED in my dev instance, but appears in +new-snap
[10:49] <cjwatson> And I cloned-and-hacked that from +new-recipe
[10:49] <wgrant> I don't believe you.
[10:49] <wgrant> But you have a good point.
[10:50] <cjwatson> I don't believe me either
[10:50] <cjwatson> And yet
[10:50] <wgrant> Maybe BuildableDistroSeries is even dodgier than I suspected.
[10:50] <cjwatson> Doesn't seem to be ...
[10:50]  * cjwatson pdbs
[10:51] <wgrant> Hm, no.
[10:51] <wgrant> It is exactly as dodgy as I remembered.
[10:51] <cjwatson> Oh, but this doesn't make any sense here
[10:52] <cjwatson> Er
[10:52] <wgrant> Oh
[10:52] <wgrant> initial_series
[10:52] <cjwatson> It's only picking one
[10:52] <wgrant> derp
[10:52] <wgrant> er, initial_values
[10:52] <cjwatson> But it ought to include FROZEN
[10:52] <wgrant> quite.
[10:52] <cjwatson> Or just use currentseries or something
[10:52] <wgrant> Indeed...
[10:52] <wgrant> It could easily accidentally pick RTM there.
[10:53] <cjwatson> Should I just use the ubuntu celebrity?
[10:53] <wgrant> I don't know if fireworks will occur if it's not actually in the vocab, and it will likely break tests.
[10:53] <wgrant> Being as bad as recipes isn't a great bar, but it's not terrible.
[10:55] <cjwatson> Let's at least include FROZEN and an XXX comment
[10:56] <wgrant> Yep
[10:56] <wgrant> Oh
[10:56] <wgrant> I guess fixing the snap case without fixing recipes wouldn't break tests, would it.
[10:56] <wgrant> But FROZEN is probably Good Enough.
[10:57] <cjwatson> BuildableDistroSeries also uses the ubuntu celebrity, which should be enough to guarantee that it's in the vocab
[10:58] <wgrant> Oh
[10:58] <wgrant> I thought it used the distros of all PPAs you could upload to.
[10:58] <cjwatson> Plus ubuntu
[10:58] <wgrant> It lists 14.09 for me.
[10:58] <cjwatson> And currentseries is always going to be active
[10:58] <wgrant> Ahh
[10:58] <wgrant> Yep
[11:07] <cjwatson> wgrant: brutal hack in place: http://bazaar.launchpad.net/~cjwatson/launchpad/snap-add-view/revision/17748
[11:11] <wgrant> cjwatson: As long as you feel bad about it. r=me.
[11:13] <cjwatson> Oh I do :P
[11:13] <cjwatson> But at least it's in a very very domain-specific place ...
[11:13] <cjwatson> Thanks.  Making good progress on a basic requestBuilds UI, which is the last significant piece of UI for this.
[11:13] <wgrant> Do you know what it looks like yet?
[11:14] <cjwatson> For now it'll just be a basic form with archive, architectures, pocket.
[11:14] <cjwatson> Which is crap but workable.
[11:14] <cjwatson> The only tricky bit is the archive selection.
[11:14] <wgrant> Pocket!?
[11:15] <wgrant> But I guess it's necessary here until we have something better.
[11:15] <cjwatson> I'm adding a widget to let you choose primary archive or a PPA.
[11:15] <wgrant> Hopefully searching PPAs
[11:15] <wgrant> Rather than showing a <select> of four hundred.
[11:15] <wgrant> Being added to Online Services teams was the worst thing that ever happened to me.
[11:15] <cjwatson> That's the intention
[11:15] <cjwatson> Haven't tested what my current code actually does yet :P
[11:16] <cjwatson> Pocket is nearly the worst piece of terminology in Launchpad.
[11:16] <wgrant> It's one of my earliest memories of Launchpad.
[11:17] <wgrant> Trying to work out what on earth the text on SP:+index meant.
[11:17] <wgrant> It survives to this day, and makes a bit less sense.
[11:17] <cjwatson> I remember Daniel swearing a lot after being told to introduce it ...
[11:17] <cjwatson> Since it involved rewriting a good chunk of the Soyuz code he had at that point
[11:18] <wgrant> Oh, I didn't realise it wasn't there from the start.
[11:18] <wgrant> It's rather more seemless history-wise than the introduction of archives.
[11:20] <cjwatson> It may have been before much was committed.
[11:21] <cjwatson> I think this was still in the phase where about 20% of Soyuz was being written in my house, and before the mega-landing on devel
[11:21] <wgrant> Heh
[11:21] <wgrant> Better than good old r4274
[11:22] <wgrant> ("Personal Package Archives")
[11:30] <wgrant> cjwatson: Do you have any planned UI filling after requestBuild?
[11:31] <cjwatson> Not at present
[11:31] <cjwatson> Do you have requests?
[11:32] <wgrant> Not until I can do them through the web UI.
[11:32] <cjwatson> Not sure I understand
[11:33] <wgrant> The last piece of UI you're working on is for making requests, and then you asked if I had more requests.
[11:33] <wgrant> It's a terrible pun, you seen.
[11:33] <wgrant> But no, I don't know of any big remaining gaps.
[11:33] <cjwatson> Sigh.  Must be Friday
[13:43] <cjwatson> wgrant: http://people.canonical.com/~cjwatson/tmp/snap-request-builds.png corresponds to https://code.launchpad.net/~cjwatson/launchpad/snap-requestBuild-ui/+merge/271650.  It's, er, basic, but works.
[13:44] <wgrant> cjwatson: It is very weird asking for pocket without series, but such is life.
[13:47] <cjwatson> I wonder if that's really a model issue.
[13:47] <cjwatson> I was thinking of it like livefs, where sometimes you want to do just one build against -proposed.
[13:48] <cjwatson> But maybe that's wrong.
[13:48] <wgrant> I wonder if snaps aren't actually series-specific.
[13:50] <cjwatson> Arguably not, since they aren't unique by series.  Though this request-builds form would be even worse if you had to pick the series every time too ...
[13:50] <wgrant> Right, but recipes have sensible defaults there
[13:50] <wgrant> Or rather they have a set of daily build series that are ignored for manual requests for some reason.
[13:50] <cjwatson> I don't think people generally want to build snaps based on more than one series of code.
[13:51] <cjwatson> And they probably don't want to flip-flop around or have to pick it every time.
[13:51] <wgrant> Right, they don't want to have to pick every time.
[13:51] <wgrant> But think about eg. charms
[13:51] <cjwatson> So I think, while a snap isn't series-specific as such, it makes sense to store that persistently.
[13:51] <wgrant> Oh certainly.
[13:51] <wgrant> A snap probably has a set of series.
[13:52] <wgrant> Now how do pockets fit in...
[13:52] <cjwatson> And IMO the bug here is really that default pockets and architectures aren't stored on the snap too.
[13:52] <wgrant> Yeah
[13:52] <cjwatson> It's definitely weird to be choosing that in separate places
[13:52] <wgrant> Maybe it has a set of suites and a set of processors.
[13:52] <cjwatson> (Well, SnapArch exists, and I'm not using it right now.  Probably should be.)
[13:52] <wgrant> Iteration!
[13:53] <cjwatson> SnapArch also has no UI
[13:55] <cjwatson> So a slight set of improvements would be (a) give SnapArch some UI, (b) move pocket to Snap, (c) drop pocket from request-builds UI, (d) default architectures in request-builds UI to Snap.processors
[13:56] <cjwatson> I don't think a set of suites makes sense.  You're building the snap *from* the suite, not *for* the suite, and it's building a static blob of everything from there.  Why would you want more than one?
[13:58] <wgrant> Is it truly everything?
[13:58] <wgrant> Surely we don't include libc in the snap.
[14:00] <cjwatson> True, and I suppose we don't really know the long-term snappy support model yet
[14:00] <wgrant> Right, exactly.
[14:01] <cjwatson> I'll at least do (d), that's fairly obviously correct
[14:14] <cjwatson> (done)
[14:16] <cjwatson> Recipes don't let you set the pocket in the UI at all, and daily builds always use RELEASE.  Which must be fun if you actually need something from -updates.
[14:17] <wgrant> Not quite
[14:17] <wgrant> They use Release in the PPA
[14:17] <cjwatson> Oh true
[14:17] <wgrant> And then the PPA's dependencies for primary.
[14:17] <cjwatson> Do we have anything else that models a set of suites?  Maybe it would be better to treat the pocket like ArchiveDependency does.
[14:17] <wgrant> You can't build directly into primary.
[14:17] <wgrant> Right, that may be more reasonable.
[14:17] <cjwatson> That is, you choose the same pocket for all suites.
[14:17] <cjwatson> er series