19:02 <infinity> #startmeeting Ubuntu Technical Board
19:02 <meetingology> Meeting started Tue Oct  9 19:02:05 2018 UTC.  The chair is infinity. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
19:02 <meetingology> 
19:02 <meetingology> Available commands: action commands idea info link nick
19:02 <infinity> Looks like we're lacking a kees, but otherwise all here.
19:02 <infinity> #topic Action Review
19:03 * infinity Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns.
19:03 <infinity> Did that happen?
19:03 <infinity> Doesn't look like it.
19:03 <Wimpress> Not yet. It will though.
19:03 <infinity> Mmkay.
19:03 * infinity infinity to ask maas team to prepare SRU exception policy à la CurtinUpdates
19:04 <infinity> As discussed in the in-person meeting in Brussels, I'm waiting on some feedback from Robie about the current state of things from his view as an SRU guy processing MaaS stuff.
19:05 * infinity formal ratification of third party seeded snap security policy
19:05 <infinity> That could do with a URL or something.
19:05 <infinity> Where is the policy we're supposed to be formally ratifying? :)
19:05 <vorlon> https://wiki.ubuntu.com/UbuntuSeededSnaps
19:05 <mdeslaur> https://wiki.ubuntu.com/UbuntuSeededSnaps
19:05 <mdeslaur> bah
19:06 <vorlon> last exchange between mdeslaur and myself was that the policy was ok with him, though I still felt that given that he had /had/ questions it was worth me clarifying the language some; but that in any event it seemed we were ready to vote on it if we had only had quorum
19:06 <infinity> Okay, we have quorum.  Do we want to take 5, read it end-to-end, then vote?
19:07 <mdeslaur> yeah
19:12 <infinity> "official Ubuntu snaps should be built only from source that is available in Launchpad." -- I still prefer an actual version-for-version source retention (even if that's just tarring up the pre-build tree and calling it the source and having that avialable somehow).
19:12 <infinity> The "repos might disappear" argument is as relevant to LP as it is to GitHub.
19:13 <stgraber> ^ same here, we had that discussion by e-mail a few times I believe, I'd prefer it if LP would just store a build artifact which is effectively the result of the snapcraft "pull" phase, splitting build between source and binary and allowing re-building the binaries from identical source if needed
19:13 <stgraber> whether that source is stored as a huge tarball or a commit in a LP-generated git tree, I don't really care
19:13 <vorlon> infinity, stgraber: so you mean that it should be ok for a build of an official snap to pull from parts hosted elsewhere at build time?
19:13 <infinity> My other concern, and maybe someone knows the answer, is how upgrades happen if we're using ubuntu-XX.XX channels.  Will that magically flip from ubuntu-18.04 to ubuntu-18.10 on upgrade, or will the user be stuc on the 18.04 branch until someone decides to obsolete it in the store and force ALL 18.04 users to a new one?
19:14 <stgraber> but having to manually setup mirroring of every single little bit of code in your snap can be a huge pain and won't help you much if one of those repo breaks or goes away on LP
19:14 <vorlon> infinity: support for that is landing in ubuntu-release-upgrader before 18.10 release
19:14 <stgraber> vorlon: so long as the stuff which was pulled is recorded and you can rebuild the binary from it, yeah
19:15 <infinity> vorlon: Okay, so non-release-upgrader upgrades (like, say, most of Ubuntu engineering) will not get the magic channel flip. :/
19:15 <vorlon> infinity: correct, apt will not do it for you
19:15 <infinity> vorlon: And yes, I don't think *where* the sources come from is relevant, if the licenses are sane and the pull result is stored as a "this is the whole source" blob.
19:15 <stgraber> what we care about is being able to re-build the binary from the same source (or a slightly modified one in the case of a security update), requiring everything be git hosted on LP makes it a lot of work for the snap publisher and doesn't actually save us from soneone doing a force push or the like
19:15 <vorlon> stgraber: well, my expectation is snapcraft tooling that facilitates populating any necessary repositories in LP, not just that users do this manually
19:17 <infinity> I'm thinking both for practical rebuild reasons, but also ease of GPL compliance.  Publishing source alongside binaries gets us out of the written offer branch of the license.
19:17 <mdeslaur> "...source that is available in launchpad" doesn't exclude having an automatically-generated tarball
19:17 <stgraber> Ideally what I'd like to see is 1) LP runs "snapcraft pull" 2) Result is a source build artifact with a mangled snapcraft.yaml that's made to used the pull bits 3) Binary builds happen completely offline using that "source" artifact
19:17 <infinity> The harder it is to obtain source, the less easy it is to claim we're providing it. :P
19:17 <vorlon> and I think the snapcraft team was regarding the "capture the tree as an artifact" as a phase one
19:17 <infinity> mdeslaur: It doesn't exclude it, but it also doesn't specify it.  Nor does it, on the surface, solve the problem it claims to be solving.
19:18 <infinity> stgraber: +1 to that.
19:18 <infinity> stgraber: Effectively making "source packages".
19:18 <stgraber> yup
19:18 <vorlon> the problem then is that the process for building a security update where you need to modify the source due to missing upstream repo doesn't match the process for building the snap the first time
19:19 <vorlon> because 'snapcraft pull' will fail
19:19 <vorlon> and also, because you don't want to pull, you want to edit your source and use that
19:19 <stgraber> vorlon: but you could just dump the content of the last source package into the git tree, apply your fix and push
19:20 <stgraber> vorlon: at which point "pull" won't do anything because all content is local to the git tree and you'll build
19:20 <mdeslaur> keeping the tarball is a backup plan, not the way forward if the repo still exists
19:20 <mdeslaur> s/is/shouldn't be/
19:20 <mdeslaur> err
19:20 <vorlon> backing up, is this the level of design involvement the TB-as-TB wants to have in these requirements?
19:20 <mdeslaur> s/is/should be/
19:21 <vorlon> because I don't think that's a design discussion that fits in this meeting
19:21 <infinity> I want to make sure the source retention policy is sane and meaningful for both rebuilds and GPL compliance.
19:21 <vorlon> does the wording need to be adjusted to account for this?
19:21 <infinity> I don't need it to be exactly my design, but "must build from LP branches" is far too vague to actually solve either issue.
19:22 <infinity> LP isn't any more magic than GitHub, the users of LP can do the same silly things and make sources go away. :)
19:23 <vorlon> ok
19:23 <infinity> And I'm still wary of pointers to commits satisfying the FSF when it comes to shipping source side-by-side.  But maybe if those commits definitely never go away and 'snapcraft pull' is somehow guaranteed to always work forever?
19:23 <vorlon> I think it's precisely the case that 'snapcraft pull' won't be required to work forever
19:23 <infinity> (Note that this isn't just a concern for by-default-on-images stuff, but literally any GPL thing in the store, and I've mentioned it repeatedly)
19:23 <vorlon> or rather that there's no way to cause it to work forever
19:24 <vorlon> since 'snapcraft pull' is doing the bit to pull from upstream repos, which may have disappeared, or had tags rudely changed, or just had tags not specified, etc
19:24 <infinity> Right, if snapcraft pull can't necessarily work forever, then we need a tarball (or similar) of *The Source* that matches those shipped binaries.
19:26 <vorlon> right; so in my mind, the ideal is that this source is the git repo which is staged in LP prior to the snap build, and which could have handwavy acls that prevent the user from deleting it after
19:26 <infinity> We can't just say "eh, in six years, that source might accidentally go away, no big deal".  My source ISOs I generate to match binary ISOs should include the source tarballs for shipped snaps, and the store should have sources easily available for any free software (and especially GPL) binary shipped.
19:27 <vorlon> rather than a tarball spit out by lp itself, which ok, then you have the source, but then you can't reinject that tarball to do a maintenance build of the snap in question
19:27 <vorlon> (reinject a modified version of the tarball)
19:28 <infinity> So, how does a user of a snap trace back from their binary to the source, in a way where we can argue they're shipped together?
19:28 <stgraber> vorlon: why wouldn't you be? the source tarball would be a buildable snapcraft tree, so you can just unpack that in the git tree of the snap, apply your patch and push
19:28 <vorlon> infinity: that needs to be in metadata in the binary snap; apologies if I failed to capture that here as a requirement
19:28 <vorlon> stgraber: what does 'push' mean?
19:29 <vorlon> like, what are you pushing to where in launchpad, that doesn't look like a confusing special case and a break with the existing snap build process?
19:30 <stgraber> vorlon: you have a LP git tree which contains the snapcraft.yaml for your snap, you clone that git tree, you wipe it clean, you unpack your source tarball in there, you apply your patch, you commit everything, you git push, you go in LP and you click the snap build button, that builds without using any external deps and pushes to the store
19:30 <infinity> vorlon: *if* the snap has metadata pointing to the exact git commit on the exact branch in LP required to reproduce the build, *and* we have guarantees that said branches will never disapper from LP, I'm fine with that proposal.  Those things need to be spelled out, though.
19:30 <stgraber> well, it is the special case though, it's the case where the snap is abandoned and the security team needs to push an update ASAP
19:30 <vorlon> ok, so you push the entire tarball to the git repo that previously included only snapcraft.yaml.  At least that makes sense from a workflow POV
19:30 <stgraber> otherwise, normal updates will be pushed by the upstream who will keep updating their snapcraftl.yaml to keep working
19:31 <vorlon> but then my question is why you don't always just push all the source to that git repo and build from it
19:31 <infinity> vorlon: I think I still need a way to pull all of that into source ISOs, for the "shipping physical media to consumers and not having to worry about written offer BS" crowd, but meh.
19:31 <stgraber> vorlon: no real reasons you couldn't other than pushing hundreds of megs of stuff into a git repo isn't all that much fun
19:32 <vorlon> maybe the deltas are smaller than that? :)
19:32 <vorlon> so should I take the action to refine the language about source retention before we vote?
19:33 <infinity> vorlon: Anyhow, my TLDR is that I don't need the design to precisely match my specs or stgraber's, but I do need the document to spell out exactly how source retention and GPL-compliance will be handled before I can sign off on it.
19:33 <infinity> vorlon: And if that needs some round-trips with the snapcraft and store teams to make sure the lanaguage matches what reality will be, so be it. :)
19:34 <infinity> vorlon: I'd also like (but won't block my vote on) some discussion around WTF we do about people like me who don't use do-release-upgrade because, well, I upgrade on release day before any of that works.
19:34 <infinity> vorlon: And, thus, if I had installed with snaps in 18.04, I'd be stuck on 18.04 snaps.. Indefinitely?
19:35 <vorlon> infinity: well, I think the mvo philosophy is that the release notes are the text version of u-r-u
19:35 * infinity grumbles.
19:35 <infinity> u-r-u was never meant to do heavy lifting, any code there was meant to be hackish workarounds for things we screwed up in packages. :P
19:36 <infinity> Not an excuse to avoid smooth upgrades.
19:36 <mdeslaur> I feel like snapd should handle release migrations itself
19:36 <infinity> It likely should.
19:36 <vorlon> snapd doesn't define the policy
19:36 <vorlon> so how should it handle the migration?
19:37 <vorlon> I would argue that if you're going to try to automate this for a user that did apt dist-upgrade before release, it should be implemented as an u-r-u fix-up mode
19:37 <infinity> It knows what release it's running on.  If you have snaps from ubuntu-18.04 and you're now running 18.10, could it not just flipperoo?
19:37 <mdeslaur> hrm
19:38 <infinity> Assuming we declare those branches as reserved keywords that mean "snaps for this release".
19:38 <vorlon> infinity: as a version-guarded one-time change in the postinst?
19:38 <mdeslaur> if we're going to name channels after releases, it should be smart enough to handle release upgrades
19:38 <vorlon> snapd isn't what names the channels
19:38 <vorlon> and the maintainers of snapd aren't the owners of the distro policy
19:39 <infinity> vorlon: Less sure about specifics.  But unless the new channels are available and populated on release opening day (seems unlikely), it's probable that the migration would be staggered for early adopters.
19:39 <vorlon> so I find it awkward to have the policy implemented in a maintainer script of a package that is owned by a team that's a fair bit removed from the upgrade handling generally
19:40 <vorlon> infinity: the channels *should* be opened on release opening day; we don't get daily image builds for the new series until they exist
19:40 <infinity> snapd tries to refresh on the regular anyway, it seems sensible that it would scan for a channel for your current release and flip you if it's found.
19:41 <infinity> This also gives third-party people a smooth way to do stable channels per release.
19:41 <infinity> Cause it would just magically DTRT on upgrade.
19:41 <infinity> (If they desire such a thing)
19:41 <infinity> Indeed, I was thinking about this when I got switched from lxd debs to snaps.
19:41 <mdeslaur> adding the release to the channel name is a workaround to snapd not knowing and not handling releases
19:42 <infinity> And it asked what I wanted (3.0 or dev or something like that?) and I wondered how it can ever return me to what we think is "right" for an LTS, eg.
19:42 <vorlon> and what does it do when the user has manually selected the 18.04 channel but is running 18.10?  I don't agree that snapd magicking this is an answer
19:42 <mdeslaur> it does the same thing as when a user manually installed a package from xenial into bionic
19:42 <vorlon> mdeslaur: I don't agree.  I don't think there's anything that snapd should know here at all
19:43 <vorlon> mdeslaur: if the user manually installed a xenial package on bionic, they can then pin it
19:43 <vorlon> the proposal here is an entirely new magic mechanism for snapd to know which channels you want, that then needs override controls when it's wrong
19:44 <infinity> Does it have no concept of state?
19:44 <vorlon> all to solve the problem that a handful of people who work on the distro itself don't use u-r-u
19:44 <vorlon> infinity: of course it does.  the state is that "something external to snapd has selected ubuntu-18.04 as a channel".
19:45 <infinity> If you select 18.04 on 18.10 when 18.04 and 18.10 exist, you wanted 18.04, weirdo.  If 18.10 suddenly appears and you're on 18.10, you want to upgade, same logic as apt and new versions.
19:45 <infinity> And by "you", I mean a human request, not an installer.
19:46 <infinity> I'd wager more than a handful of people don't use u-r-u.
19:46 <vorlon> well, we're spending a lot of time here on something you said was not a blocker
19:46 <infinity> Of course, I'd also argue that the more we talk about how to integrate snaps in the distro, the more I'm convinced it's not really a reasonable thing to be doing.
19:46 <infinity> So... Yay?
19:46 <vorlon> I'm sure there are lots of people who *don't* use u-r-u.  But that doesn't mean they *shouldn't* be using u-r-u or that we should spend extra engineering effort supporting them
19:47 <infinity> If we refuse to let snapd have any knowledge about releases and how to interact with release upgrades, it's just plain not a first-class citizen here.  An external tool to fudge it isn't making that better.
19:50 <infinity> Anyhow, I think we've wasted enough time being grumpy about all of that, and the source retention policy stuff is more important and still an open question, so ending this.
19:50 <mdeslaur> infinity, stgraber: do you have any other objections to the policy other than the source availability?
19:51 <stgraber> nope, that's the only issue I have with it at this time
19:51 * infinity vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear.
19:51 <vorlon> ack
19:51 <vorlon> thanks
19:51 <infinity> mdeslaur: The upgrade thing will nag at me, but like I said before we started arguing about it, I won't block on that.  Source retention is my blocker.
19:52 <infinity> #topic doko's stuff.
19:52 <mdeslaur> infinity: ack, thanks
19:52 <infinity> We still have three bullet points from doko on the Agenda.  Do we want to do anything about those?  Any discussion?  Delete them so I can stop looking at them every two weeks?
19:53 <vorlon> infinity: +1, with notification to doko that this has been done
19:55 <stgraber> +1 on dropping
19:55 <infinity> vorlon: As long as someone other than me does the notifying.  doko's already pretty sure I hate him. :P
19:55 <mdeslaur> lol
19:56 <infinity> #topic Mailing List!
19:56 <vorlon> heh
19:57 <infinity> So, TB elections started, and then stopped again.  Exciting times.  Go, democracy.
19:57 <infinity> I assume it'll re-start again soon with a fixed ballot. :P
19:57 <stgraber> hopefully will take less time to setup than last time around :)
19:57 <infinity> And then there's the bit about switching the default Ubuntu VCS to git.  Which appears to have happened.
19:57 <infinity> So yay to that.
19:58 <infinity> #topic Community Bugs
19:58 <infinity> None. :(
19:58 <infinity> The community needs to bug us more.
19:58 <infinity> #topic Next Chair
19:59 <infinity> Looks like kees with mdeslaur as backup, if we don't all get replaced in the election that may or may not happen.
19:59 <mdeslaur> sounds good to me
19:59 <infinity> #topic AOB
19:59 <infinity> You have 30 seconds for other business before I close this mess and go think about all the life decisions that led me here.
20:00 <mdeslaur> lol
20:00 <infinity> #endmeeting