== Meeting information == * #ubuntu-meeting-2: Ubuntu Technical Board, 09 Oct at 19:02 — 20:00 UTC * Full logs at [[http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2018/ubuntu-meeting-2.2018-10-09-19.02.log.html]] == Meeting summary == === Action Review === The discussion about "Action Review" started at 19:02. * ''LINK:'' https://wiki.ubuntu.com/UbuntuSeededSnaps * ''LINK:'' https://wiki.ubuntu.com/UbuntuSeededSnaps === doko's stuff. === The discussion about "doko's stuff." started at 19:52. === Mailing List! === The discussion about "Mailing List!" started at 19:56. === Community Bugs === The discussion about "Community Bugs" started at 19:58. === Next Chair === The discussion about "Next Chair" started at 19:58. === AOB === The discussion about "AOB" started at 19:59. == Vote results == == Done items == * (none) == People present (lines said) == * infinity (76) * vorlon (48) * mdeslaur (18) * stgraber (17) * meetingology (3) * Wimpress (1) == Full Log == 19:02 #startmeeting Ubuntu Technical Board 19:02 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 19:02 Available commands: action commands idea info link nick 19:02 Looks like we're lacking a kees, but otherwise all here. 19:02 #topic Action Review 19:03 * infinity Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. 19:03 Did that happen? 19:03 Doesn't look like it. 19:03 Not yet. It will though. 19:03 Mmkay. 19:03 * infinity infinity to ask maas team to prepare SRU exception policy à la CurtinUpdates 19:04 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 That could do with a URL or something. 19:05 Where is the policy we're supposed to be formally ratifying? :) 19:05 https://wiki.ubuntu.com/UbuntuSeededSnaps 19:05 https://wiki.ubuntu.com/UbuntuSeededSnaps 19:05 bah 19:06 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 Okay, we have quorum. Do we want to take 5, read it end-to-end, then vote? 19:07 yeah 19:12 "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 The "repos might disappear" argument is as relevant to LP as it is to GitHub. 19:13 ^ 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 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 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 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 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 infinity: support for that is landing in ubuntu-release-upgrader before 18.10 release 19:14 vorlon: so long as the stuff which was pulled is recorded and you can rebuild the binary from it, yeah 19:15 vorlon: Okay, so non-release-upgrader upgrades (like, say, most of Ubuntu engineering) will not get the magic channel flip. :/ 19:15 infinity: correct, apt will not do it for you 19:15 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 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 stgraber: well, my expectation is snapcraft tooling that facilitates populating any necessary repositories in LP, not just that users do this manually 19:17 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 "...source that is available in launchpad" doesn't exclude having an automatically-generated tarball 19:17 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 The harder it is to obtain source, the less easy it is to claim we're providing it. :P 19:17 and I think the snapcraft team was regarding the "capture the tree as an artifact" as a phase one 19:17 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 stgraber: +1 to that. 19:18 stgraber: Effectively making "source packages". 19:18 yup 19:18 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 because 'snapcraft pull' will fail 19:19 and also, because you don't want to pull, you want to edit your source and use that 19:19 vorlon: but you could just dump the content of the last source package into the git tree, apply your fix and push 19:20 vorlon: at which point "pull" won't do anything because all content is local to the git tree and you'll build 19:20 keeping the tarball is a backup plan, not the way forward if the repo still exists 19:20 s/is/shouldn't be/ 19:20 err 19:20 backing up, is this the level of design involvement the TB-as-TB wants to have in these requirements? 19:20 s/is/should be/ 19:21 because I don't think that's a design discussion that fits in this meeting 19:21 I want to make sure the source retention policy is sane and meaningful for both rebuilds and GPL compliance. 19:21 does the wording need to be adjusted to account for this? 19:21 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 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 ok 19:23 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 I think it's precisely the case that 'snapcraft pull' won't be required to work forever 19:23 (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 or rather that there's no way to cause it to work forever 19:24 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 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 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 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 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 (reinject a modified version of the tarball) 19:28 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 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 infinity: that needs to be in metadata in the binary snap; apologies if I failed to capture that here as a requirement 19:28 stgraber: what does 'push' mean? 19:29 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 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 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 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 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 otherwise, normal updates will be pushed by the upstream who will keep updating their snapcraftl.yaml to keep working 19:31 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 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 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 maybe the deltas are smaller than that? :) 19:32 so should I take the action to refine the language about source retention before we vote? 19:33 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 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 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 vorlon: And, thus, if I had installed with snaps in 18.04, I'd be stuck on 18.04 snaps.. Indefinitely? 19:35 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 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 Not an excuse to avoid smooth upgrades. 19:36 I feel like snapd should handle release migrations itself 19:36 It likely should. 19:36 snapd doesn't define the policy 19:36 so how should it handle the migration? 19:37 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 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 hrm 19:38 Assuming we declare those branches as reserved keywords that mean "snaps for this release". 19:38 infinity: as a version-guarded one-time change in the postinst? 19:38 if we're going to name channels after releases, it should be smart enough to handle release upgrades 19:38 snapd isn't what names the channels 19:38 and the maintainers of snapd aren't the owners of the distro policy 19:39 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 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 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 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 This also gives third-party people a smooth way to do stable channels per release. 19:41 Cause it would just magically DTRT on upgrade. 19:41 (If they desire such a thing) 19:41 Indeed, I was thinking about this when I got switched from lxd debs to snaps. 19:41 adding the release to the channel name is a workaround to snapd not knowing and not handling releases 19:42 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 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 it does the same thing as when a user manually installed a package from xenial into bionic 19:42 mdeslaur: I don't agree. I don't think there's anything that snapd should know here at all 19:43 mdeslaur: if the user manually installed a xenial package on bionic, they can then pin it 19:43 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 Does it have no concept of state? 19:44 all to solve the problem that a handful of people who work on the distro itself don't use u-r-u 19:44 infinity: of course it does. the state is that "something external to snapd has selected ubuntu-18.04 as a channel". 19:45 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 And by "you", I mean a human request, not an installer. 19:46 I'd wager more than a handful of people don't use u-r-u. 19:46 well, we're spending a lot of time here on something you said was not a blocker 19:46 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 So... Yay? 19:46 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 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 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 infinity, stgraber: do you have any other objections to the policy other than the source availability? 19:51 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 ack 19:51 thanks 19:51 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 #topic doko's stuff. 19:52 infinity: ack, thanks 19:52 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 infinity: +1, with notification to doko that this has been done 19:55 +1 on dropping 19:55 vorlon: As long as someone other than me does the notifying. doko's already pretty sure I hate him. :P 19:55 lol 19:56 #topic Mailing List! 19:56 heh 19:57 So, TB elections started, and then stopped again. Exciting times. Go, democracy. 19:57 I assume it'll re-start again soon with a fixed ballot. :P 19:57 hopefully will take less time to setup than last time around :) 19:57 And then there's the bit about switching the default Ubuntu VCS to git. Which appears to have happened. 19:57 So yay to that. 19:58 #topic Community Bugs 19:58 None. :( 19:58 The community needs to bug us more. 19:58 #topic Next Chair 19:59 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 sounds good to me 19:59 #topic AOB 19:59 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 lol 20:00 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)