| * tsimonq2 waves, albeit a few mins early | 18:57 | |
| mdeslaur | \o | 18:58 |
|---|---|---|
| kees | o/ | 19:00 |
| * slangasek waves | 19:00 | |
| mdeslaur | hi kees | 19:00 |
| mdeslaur | hi slangasek | 19:00 |
| kees | 3 ... anyone else? | 19:01 |
| slangasek | I understand stgraber is on vacation this week, no idea what that implies for his TB meeting attendance | 19:01 |
| kees | no quorum with 3. whee | 19:02 |
| slangasek | is 3 not quorum? | 19:02 |
| slangasek | I thought we've certainly been treating it as such | 19:03 |
| kees | oh! | 19:03 |
| kees | ok | 19:03 |
| kees | #start-meeting | 19:04 |
| slangasek | no-dash? | 19:04 |
| kees | #startmeeting | 19:04 |
| meetingology | Meeting started Tue Apr 10 19:04:35 2018 UTC. The chair is kees. Information about MeetBot at http://wiki.ubuntu.com/meetingology. | 19:04 |
| meetingology | Available commands: action commands idea info link nick | 19:04 |
| kees | ah | 19:04 |
| kees | action review: | 19:05 |
| kees | ACTION: flexiondotorg To follow-up on-list with design review to address MATE Boutique security/consent concerns. | 19:05 |
| slangasek | I haven't seen anything on the list | 19:05 |
| mdeslaur | doesn't look like he did | 19:05 |
| slangasek | and he's currently off irc | 19:06 |
| kees | yeah | 19:06 |
| tsimonq2 | Wimpress is his new nick. | 19:06 |
| slangasek | oh | 19:06 |
| slangasek | Wimpress: ^^ ? | 19:07 |
| Wimpress | o/ | 19:07 |
| kees | ACTION: tsimonq2 to propose patches to maintenance-check regarding Lubuntu Next (done in https://code.launchpad.net/~tsimonq2/ubuntu-archive-publishing/lubuntu-next-support-cycle-adjustment/+merge/342475 | 19:07 |
| kees | oh | 19:07 |
| Wimpress | This is not forgotten. | 19:07 |
| Wimpress | I'll try and get round to this in the next week. | 19:07 |
| mdeslaur | Wimpress: what's with the disguise? | 19:07 |
| tsimonq2 | mdeslaur: #blameflocculant | 19:07 |
| Wimpress | Long story. | 19:07 |
| mdeslaur | hehe | 19:07 |
| Wimpress | But that ^ | 19:07 |
| Wimpress | We've already dropped a bunch a PPA and repos from Welcome as a start on this. | 19:08 |
| Wimpress | But I will post to the ML with a full proposal soon | 19:08 |
| mdeslaur | ack, thanks | 19:09 |
| kees | cool. deferred | 19:09 |
| slangasek | Wimpress: ok; bearing in mind that the TB's request was not that you drop the support for third-party repos necessarily, but that you disclose to the user what is happening | 19:10 |
| kees | tsimonq2: how about your action? | 19:10 |
| Wimpress | slangasek: Yes, I know. But I felt this was a good time to review what we were listing. | 19:10 |
| tsimonq2 | kees: It's done; I'm the one who modified the agenda with the link in there. ;) | 19:11 |
| slangasek | yes, I reviewed and merged the change | 19:12 |
| slangasek | tsimonq2: have you verified that the result is correct in the archive metadata? | 19:12 |
| kees | oh durp | 19:12 |
| tsimonq2 | slangasek: No; where can I do that? | 19:12 |
| slangasek | tsimonq2: Packages.gz | 19:12 |
| slangasek | tsimonq2: Supported field | 19:13 |
| kees | ACTION: infinity to call for confirmation of LTS status from all flavours. | 19:13 |
| tsimonq2 | One minute then; you're free to move on to other items. | 19:13 |
| kees | no infinity so deferred | 19:13 |
| slangasek | tsimonq2: qlubuntu-default-session still shows as Supported: 3y which I think indicates it didn't have the intended result yet; you and I can iterate | 19:14 |
| kees | ACTION: infinity to ask maas team to prepare SRU exception policy à la CurtinUpdates | 19:14 |
| kees | also deferred | 19:14 |
| kees | agenda items... | 19:14 |
| kees | [slangasek] - Review of the seeded snaps policy | 19:15 |
| slangasek | hello | 19:15 |
| slangasek | [LINK] https://wiki.ubuntu.com/UbuntuSeededSnaps | 19:15 |
| tsimonq2 | slangasek: The source package is shared. That's not an accurate representation. | 19:15 |
| slangasek | tsimonq2: afaik supported fields are per-binary, not per-source; anyway, feel free to find one that you know should be 9m and check the result :) | 19:15 |
| slangasek | kees, mdeslaur: I didn't send any follow-up emails, I think the agreement last time was that TB members would review this spec in their own time and we could discuss at this meeting. Did you have a chance to review the spec? | 19:16 |
| mdeslaur | I did review the spec, I have a few questions | 19:16 |
| tsimonq2 | slangasek: Ah, so indeed, it didn't set correctly. | 19:17 |
| tsimonq2 | #action tsimonq2 to investigate why the Lubuntu Next support time modifications are not set correctly | 19:17 |
| meetingology | ACTION: tsimonq2 to investigate why the Lubuntu Next support time modifications are not set correctly | 19:17 |
| tsimonq2 | Anyway, sorry, carry on. | 19:18 |
| slangasek | mdeslaur: excellent, I'm happy to make up answers :) | 19:18 |
| mdeslaur | The spec doesn't define who acts as the gatekeeper between core devs and publishing a snap directly to users | 19:19 |
| mdeslaur | like the way it is currently handled | 19:19 |
| slangasek | in the sense of archive review? | 19:19 |
| mdeslaur | yes. In the sense that currently a core dev can't push an update directly to users | 19:20 |
| slangasek | ah; so perhaps more in the sense of SRU | 19:20 |
| mdeslaur | without going through the sru team, etc | 19:20 |
| slangasek | yes; I think the design of the snap store, and the relative isolation of snaps, means we should aim to have less process around this generally, | 19:21 |
| slangasek | because e.g. reverts are a lot easier, and eventually should be drivable with health checks | 19:22 |
| slangasek | etc | 19:22 |
| slangasek | so at this time I wasn't aiming to dictate any gatekeeping around this, or to forklift import the SRU policy | 19:22 |
| kees | i only had one question: how are seeded snaps distinguished from third party snaps? given the higher policy requirements for seeded snaps, end users may only want seeded snaps | 19:23 |
| slangasek | mdeslaur: do you think that's ok for now, or do you think we need gatekeepers initially? | 19:24 |
| mdeslaur | won't there be third party seeded snaps too? | 19:24 |
| mdeslaur | slangasek: I personally think this makes becoming a core-dev or attempting to steal core-dev credentials much more attractive for people with bad intentions | 19:25 |
| slangasek | ok | 19:25 |
| kees | mdeslaur: seeded snap policy says everything has to be in LP (source and builds), so i think no 3rd party? | 19:25 |
| mdeslaur | "...to be included in an Ubuntu image, a snap should have as its publisher either the upstream..." | 19:26 |
| slangasek | mdeslaur: in practice, we don't gate uploads to the devel series by core-devs, after initial NEW processing; so it's a difference in window of opportunity (you can upload a hostile snap and have it instantly take effect for stable users, vs. having to upload to devel and wait and see) | 19:27 |
| jbicha | that's interesting for the use case of Firefox where we got mozilla building the snap | 19:27 |
| slangasek | mdeslaur: and in practice the store doesn't give us many layers of gatekeeping against collaborators | 19:27 |
| mdeslaur | slangasek: right, but the devel series is a buffer that (in theory) allows review by others, and damage can be reverted before hitting users | 19:27 |
| slangasek | kees: so in this case you're defining third-party as "not built on trusted infrastructure"? | 19:28 |
| kees | i guese, yes. "snaps installed by default we should ensure that they are built from source in the same trusted Launchpad environment in which debs are built" | 19:29 |
| slangasek | yes, firefox is an interesting case, and there are different requirements that are in tension. I think we should punt on firefox in the context of this discussion | 19:29 |
| slangasek | (firefox snap is not seeded in 18.04 desktop, AFAIK; we have time) | 19:31 |
| kees | the policy (source can't disappear, built on LP) is a higher bar, so making those discoverbale seems like it'd have value to end users | 19:31 |
| kees | beyond that, i like the policy | 19:31 |
| slangasek | kees: anyway, to your question of distinguishing them, the intent is that this be surfaced as metadata in the snap store, which the store could expose to the end user over the snapd api | 19:31 |
| kees | perfect | 19:32 |
| jbicha | (yes, AFAIK firefox snap isn't proposed for inclusion in Ubuntu by default yet) | 19:32 |
| slangasek | I'm working with the store team on the implementation details, but yes, it's important that this be auditable and not taken on faith that a given snap is done correctly :) | 19:32 |
| kees | mdeslaur: are your questions/concerns addressed? | 19:32 |
| mdeslaur | I like the policy as it applies to snaps built in launchpad from known sources, and security support has been commited to | 19:32 |
| mdeslaur | I don't know how third party or upstream snaps fit into that | 19:33 |
| slangasek | mdeslaur: per current policy, a "third party" or "upstream" snap is fine but they still need to build the binary on LP to comply with this policy | 19:33 |
| mdeslaur | how the mechanism for taking control of that snap if adequate security isn't being provided? | 19:34 |
| mdeslaur | s/how/what's/ | 19:34 |
| jbicha | (and the third party needs to be in a LP team approved by the DMB) | 19:35 |
| mdeslaur | Let's say we allow an upstream snap, built on launchpad in bionic, and upstream decides to no longer build security updates for the bionic snap once the next LTS rolls out, for example | 19:36 |
| slangasek | mdeslaur: today, we would try to talk to the publisher first, or the store team as necessary, to get collaborator access and publish our updates to the stable/ubuntu-XX.YY channels | 19:36 |
| slangasek | jbicha: that's an interesting point; I don't think it follows from the current policy as written | 19:37 |
| kees | slangasek, mdeslaur: sounds like security support policy needs to get fleshed out more? should that continue in email? | 19:37 |
| jbicha | slangasek: oh | 19:38 |
| slangasek | note that the snap store doesn't actually use launchpad teams; publishers / collaborators are implemented only store side and are defined in terms of assertions and keys | 19:38 |
| slangasek | so we can't actually enforce that every collaborator on a third-party snap is part of a DMB-approved LP team | 19:38 |
| kees | [action] slangasek and mdeslaur to more clearly define third party seeded snap security policy | 19:40 |
| meetingology | ACTION: slangasek and mdeslaur to more clearly define third party seeded snap security policy | 19:40 |
| kees | how's that look? | 19:40 |
| slangasek | if that is the action from mdeslaur's POV, sure :) | 19:41 |
| mdeslaur | It may be easier to get this accepted in two steps: 1- community-maintained, launchpad-built snaps, and then 2- thirty party snaps | 19:41 |
| kees | 20 minutes left, so let's move on for now... | 19:41 |
| kees | [tsimonq2] - The rationale for snapd being in the platform seed when flavors weren't polled first. | 19:41 |
| mdeslaur | ok | 19:42 |
| tsimonq2 | Hi. | 19:42 |
| tsimonq2 | I am wondering, out of curiosity, why snapd was added to the desktop-common seed without flavors being consulted: https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.bionic/revision/2056 | 19:42 |
| tsimonq2 | I oppose to shipping snapd in Lubuntu by default due to some serious usability concerns that I have raised with the Snapcraft team, as well as bug 1730159 among other things. | 19:42 |
| tsimonq2 | This isn't an issue right now, because Lubuntu doesn't pull in recommends and I've manually blacklisted it just in case, but it becomes an issue when we turn off no-follow-recommends at the beginning of next cycle. | 19:42 |
| tsimonq2 | I would like to request the removal of snapd from desktop-common, even as recommended, because Lubuntu does not want to ship this as part of our default install, unless of course it's mandated by the Technical Board. I would also like to know why this decision was made without asking flavors, unless I am missing some historical context or something else here. | 19:42 |
| tsimonq2 | Thanks. | 19:43 |
| slangasek | right | 19:44 |
| slangasek | so, I have certainly defended the principle recently that the desktop-common seed in particular should be subject to consensus among the desktop flavors, and should not be used to force things into the common platform over objections ;) | 19:45 |
| tsimonq2 | You have. :) | 19:45 |
| slangasek | you will however note that I am the committer of that revision and are right to call out the disconnect | 19:45 |
| slangasek | so here's my position | 19:45 |
| slangasek | the fact that it's in the desktop-common seed is actually an implementation detail | 19:46 |
| slangasek | from the perspective of Canonical, and the Foundations Team, snapd is now part of the standard Ubuntu experience | 19:46 |
| slangasek | anyone who installs Ubuntu, in any of its forms, should be able to 'snap install' the same way they're able to 'apt install' | 19:47 |
| slangasek | in practice it's separately seeded in desktop-common and in server, but the intent is that it's part of the common platform experience | 19:47 |
| slangasek | this is subject to TB review, of course | 19:47 |
| tsimonq2 | Right, and this is me bringing it to TB review. :) | 19:48 |
| kees | seems like snapd should be part of the per-flavor *-desktop ? | 19:48 |
| slangasek | but that at least gives the rationale for not consulting flavors - it was a platform-level decision | 19:48 |
| kees | or *-minimal, or something? | 19:48 |
| tsimonq2 | And the "standard Ubuntu experience" is defined by Canonical, not by the Ubuntu Technical Board or another similar body? Or does this come from sabdfl? | 19:49 |
| slangasek | depending on the result of TB review, we can move it to a more appropriate seed(s) for clarity | 19:49 |
| slangasek | tsimonq2: the TB doesn't often get asked to sign off on platform changes up front | 19:49 |
| slangasek | I don't think the upstart->systemd move was TB-ratified, to give one example | 19:50 |
| tsimonq2 | kees: I agree with you. | 19:50 |
| slangasek | but the TB is certainly the right forum for appeal | 19:50 |
| kees | seems like even this doesn't need to come to TB. snap availability should be a flavor-specific option, yes? | 19:50 |
| kees | slangasek: by "standard Ubuntu experience" do you mean "all ubuntu flavors"? | 19:51 |
| tsimonq2 | kees: Correct, but we weren't given the choice. | 19:51 |
| slangasek | kees: yes | 19:51 |
| kees | aaah | 19:51 |
| kees | hm | 19:51 |
| mdeslaur | just like all flavours use the standard kernel, and repos, etc. | 19:51 |
| kees | right | 19:51 |
| kees | okay, I misparsed the "standard Ubuntu" to mean "Ubuntu-the-flavor" | 19:52 |
| tsimonq2 | But, "standard Ubuntu experience" is Canonical-defined? Is that at least public? | 19:52 |
| kees | You really mean "universal Ubuntu experience" | 19:52 |
| mdeslaur | I think it would be a disservice to users to have a specific flavour be missing some software installation sources | 19:52 |
| slangasek | kees: yes, sorry | 19:52 |
| tsimonq2 | mdeslaur: Even if it's one command away to install and it's not being used by default, at all? | 19:53 |
| tsimonq2 | Er, s/used/utilized/. | 19:53 |
| kees | tsimonq2: if bug 1730159 was solved, how would you feel about Lubuntu with snapd installed? | 19:53 |
| tsimonq2 | kees: Much more inclined. | 19:54 |
| tsimonq2 | But I would still take an additional look. | 19:54 |
| mdeslaur | tsimonq2: having a webpage instruct a user to do a "snap install" but then have a special section how to do it on a specific flavour would be a disservice to users | 19:54 |
| kees | okay, then I see two issues here: the *specific* case of snapd in Lubuntu (seemingly solved with bug 1730159 getting fixed), and the desire to have a policy on things getting added to all flavors without notification of the flavors. | 19:54 |
| mdeslaur | tsimonq2: but if you have technical objections that can be fixed, then I'm sure they could be addressed | 19:55 |
| tsimonq2 | mdeslaur: I see. | 19:55 |
| tsimonq2 | kees: Bingo. | 19:55 |
| kees | slangasek: you've already commented on that bug; how feasible would it be to solve this before 18.10? | 19:55 |
| kees | tsimonq2, mdeslaur: it sounds like that for 18.04, Lubuntu will need that extra instruction, since it _isn't_ installed there currently. | 19:56 |
| slangasek | tsimonq2: so, "does this come from sabdfl" - Canonical is his company, the company has put a lot of money into developing the snap store and experience, and therefore you can expect the barrier for overturning such a platform decision to be somewhat high (even to the point that yes, sabdfl might directly put his thumb on the scale). As mdeslaur says, Canonical's interest here would instead be | 19:56 |
| slangasek | to focus on improving snapd so that it met the needs of our flavors | 19:56 |
| tsimonq2 | kees: Does the TB expect me to put snapd back? | 19:56 |
| tsimonq2 | I can, if needed. | 19:57 |
| kees | tsimonq2: I don't know; that's why I'm bringing that up -- as things stand, it's not installed. but it's a Recommend and Lubuntu doesn't install Recommends by default, so ... everything is working as expected right now | 19:57 |
| slangasek | kees: I would say that LP: #1730159 should even be solved in 18.04 (though perhaps not before GA) | 19:57 |
| kees | the statements made about it seem to aim at 18.10 when those defaults will change for lubuntu | 19:57 |
| tsimonq2 | slangasek: OK. I am not saying that I don't like snapd and I don't want to ship it, I'm saying that I see shortcomings to doing that before some problems are solved. | 19:57 |
| kees | okay, almost out of time. | 19:58 |
| kees | should we keep an action about flavor-wide default package notifications? | 19:58 |
| tsimonq2 | I think so. | 19:58 |
| slangasek | perhaps you want to scope that to "daemons" | 19:58 |
| tsimonq2 | kees: installed by default> ack | 19:58 |
| slangasek | since that's really the only thing that makes snapd problematic, compared to all the other changes Foundations makes unsupervised | 19:59 |
| kees | that seems reasonable to me. | 19:59 |
| mdeslaur | I think that's reasonable also | 19:59 |
| tsimonq2 | I can remove snapd from the Lubuntu blacklist, but if Canonical wants snapd, they can raise it to a Depends. :) | 19:59 |
| kees | tsimonq2: are you will to write up the language for such a policy? then we can review it on email and take it to the next meeting? | 20:00 |
| tsimonq2 | Absolutely. | 20:00 |
| kees | [action] tsimonq2 to email proposed policy for flavor-notification of daemons being added to all flavors (e.g. snapd into desktop-common) | 20:00 |
| meetingology | ACTION: tsimonq2 to email proposed policy for flavor-notification of daemons being added to all flavors (e.g. snapd into desktop-common) | 20:00 |
| kees | okay, that's time! :) | 20:01 |
| kees | #endmeeting | 20:01 |
| tsimonq2 | o/ | 20:01 |
| meetingology | Meeting ended Tue Apr 10 20:01:06 2018 UTC. | 20:01 |
| meetingology | Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2018/ubuntu-meeting-2.2018-04-10-19.04.moin.txt | 20:01 |
| slangasek | hah | 20:01 |
| slangasek | thanks, all :) | 20:01 |
| kees | thanks! | 20:01 |
| mdeslaur | thanks everyone! | 20:01 |
| tsimonq2 | Thanks! (now that my connection is better) | 20:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!