20:04 #startmeeting 20:04 Meeting started at 20:04:33 UTC. The chair is vorlon. Information about MeetBot at https://wiki.ubuntu.com/meetingology 20:04 (just because you're next on the list) 20:04 Available commands: action, commands, idea, info, link, nick 20:04 [topic] apologies 20:04 #topic apologies 20:05 nothing seen on the mailing list 20:05 #topic Action review 20:05 * vorlon formal ratification of third party seeded snap security policy, depends on: (rbasak, 19:06) 20:05 I don't understand this dependency statement 20:05 It relies on the following line 20:05 oh sorry - the latter bit is just timestamp etc and it depends on the next item 20:06 * vorlon vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. 20:06 carry-over 20:06 * vorlon vorlon to reply to seeded snap upload permissions question on list 20:06 carry-over 20:06 * vorlon sil2100 to start a draft summarizing the OEM archive portion of the meeting which xnox and TB will review, edit, and ratify before we move on to figuring out the next step 20:06 Yes 20:06 Sort of mixed up in all of this is to make progress on the requirements pad 20:06 yes it's done? :) 20:06 (previous item) 20:06 * vorlon nods 20:06 So I have the draft in progress, last time I mentioned that I needed some additional info about the state of the OEM archive. We discussed it a bit 20:06 I was able to get some information 20:07 great 20:07 do you need anything more from us? 20:07 The things I was previously thinking about was: who has access to the OEM archive (upload rights) and what processes they follow 20:07 I got some documents from the OEM team and I still need to read them up, but basically the main uploaders are part of this team: 20:08 https://launchpad.net/~oem-archive/+members 20:08 fwiw, I raised an eyebrow at the response on ubuntu-devel to your recent email 20:08 which says that OEM builds default to release upgrades being disabled 20:08 o_O 20:08 Yeah, I don't remember knowing about that! 20:08 First time I hear it 20:08 I talked with the Desktop Team about it this morning, they didn't know either 20:08 We did wonder what rules the OEM builds followed. Turns out they exist without any TB input or approval. 20:09 So it seems like exactly how they behave hasn't really ever been reviewed. 20:09 (by anyone wearing an Ubuntu hat) 20:09 rbasak: I'll check the docs and materials they gave me and update the OEM archive wiki page. The good news is they have quite a formalized release process for their packages 20:09 And perhaps that needs to happen 20:10 I appreciate the progress you're making on this sil2100! 20:10 Like, there's a lot of automation, every package update has a special LP bug that triggers automation and there are clear steps on how things move from one stage to another 20:10 But sadly, I didn't wrap my head around it yet 20:10 For the record, the OEM archive draft is in progress here: https://wiki.ubuntu.com/OEMArchive 20:10 But no progress yet since last week! 20:11 ok, thanks for the summary/update 20:11 Let's carry it over for now, but I think at least there's progress 20:11 #topic ACTION: all members to continue discussion at https://pad.ubuntu.com/third-party-repository-requirements 20:11 how's this going? :) 20:12 I'd like to run through where we are per proposed requirement please. 20:12 ok 20:12 I think some are differently blocked and it'd be good to clear them up so I can try and turn them into drafts. 20:13 Prop. req. A: I provided draft wording as we discussed previously. Does vorlon have feedback on that please? 20:14 sil2100 and mdeslaur: am I right in thinking that you don't want to diverge from the user expectation of stability, and therefore are in favour of the proposal if we can figure out details? Or something else? 20:14 just trying to suss out ordering of the comments in that etherpad; oh to be doing this in git (or even google docs) 20:15 Yeah I regret using the pad. If everyone's fine with it I can migrate to Google Docs. 20:15 (but cyphermox isn't here) 20:15 rbasak: I don't think it is up to make that decision. But I am in favour of the status quo of the proposal 20:15 I don't think you need to mention channel there, "the snap presented to Ubuntu users" encompasses this 20:15 s/up to/up to us/ 20:15 vorlon: removed, thanks 20:16 rbasak: otherwise I think it looks good, captures the intent, and of course we know up front the browser gets an exception 20:16 mdeslaur: could you add yourself to "Support:" in that case please? Or do I misunderstand? 20:17 And same to vorlon :) 20:17 ack 20:17 as it happens I was just looking at seeded snaps on the focal desktop today, due to fixing a livecd-rootfs bug 20:17 ok, added 20:17 would it be worth talking about what's currently there? 20:17 (and look, my colour changed) 20:18 vorlon: you mean in terms of which packages will need an exception? 20:18 yes 20:19 particularly as, uh, some of the dependency snaps have changed since 20.04 release 20:19 I suppose in particular we should understand if there are any packages that currently have a de-facto exception that we would like to withdraw. 20:20 sil2100: your opinion please on the status quo? 20:20 Yeah, a discussion with seeded snap owners might be helpful here 20:20 20.04.3 shipped with gnome-3-34-1804; 20.04 daily now has gnome-3-38-2004 20:20 fwiw 20:20 so I'm sure gnome-3-34-1804 is very stable :P 20:20 Since my worry was that basically the expectatio of snaps is that they can be quickly deployed and updated, so maybe some users actually expect snaps to be the newest version around always 20:20 In order to make progress, I actually think I'd prefer to see the general case agreed upon, and then worry about specific cases and exceptions later. 20:20 ack 20:21 sil2100: but they don't know it's a snap. It's there by default (for example). 20:21 But thinking about it more I guess let's just try keeping this standard, maybe by requiring the usage of per-release tracks 20:22 And if they want to opt-in to always-update, then that's usually available to opt-in to. 20:22 Ok, added my +1 on that then 20:22 Thanks 20:22 True! 20:22 So prop. req. B next 20:22 Valid point, they can just switch tracks then 20:22 I think we have general support, so maybe this is just an action for me to draft the wording for further discussion. 20:22 Any other comments? 20:23 (on how to proceed) 20:23 +1 20:23 And same for C and D. 20:23 This is something that was bothering us at the release team since ages, requirement B 20:24 Even such simple things as opening a branch or promoting some snap always required going back and forth with the owners of the snap 20:24 sil2100: your 'support' on B has a footnote though? 20:26 I think I generally agree, I think my footnote was just about having power for selected subsets of users 20:27 so do you want language amended / fleshed out here to capture this? 20:28 do we want to be able to override ownership if the publisher is unresponsive, or do we want to have rights from the get go? 20:28 Just specifying that it's not just about the uploading, but also about promoting from channel to channel - but I'd say this would have to be limited to say release-team for given tracks 20:28 Tracks/branches 20:29 But maybe that's overcomplicating things, as this would require changes to the store possibly 20:29 well - to be clear, my assumption is that we are ONLY guaranteed to have rights to override the per-Ubuntu-release channels 20:29 mdeslaur: I don't mind as long as it's possible, and to make progress I'm trying to get consensus on the requirement first, over how exactly it must be implemented. 20:29 ok 20:29 (and then we can approve specific implementations later) 20:30 needing the ability to update firefox on the latest/stable/ubuntu-22.04 channel definitely doesn't mean we get to update latest/stable 20:32 right 20:32 and the snap store permissions model (i.e. no such thing as groups/teams) means that granting the release team prior access to open/close channels isn't a good solution either 20:33 Any further discussion on B? 20:33 ok, anything else about B? 20:33 sil2100: so my $.02, I'm sensitive to the frustrations of the release team (I, too, have been annoyed by image builds blocked at release opening due to missing snap channels), but I don't think there's anything we should change here in the TB requirements 20:34 All good here now 20:34 Anything to say on C or D, or with the general agreement we have are we good to leave me to draft those? 20:35 Yeah, I think it's okay as is, we can think of a way to fix the channel management problem some other time 20:35 I'm good w/ C, D 20:36 I'm good with C as long as security updates and testing is mentioned 20:36 Yeah, I think the only comment was to maybe include req G as part of C? 20:37 I'm not sure I feel the need to require G. 20:37 How do others feel about this? 20:37 as long as testing is mentioned in C, we can get rid of G 20:38 Ubuntu membership would probably be granted to anyone consistently maintaining a package and meeting our requirements anyway, I think? Ie. fulfilling C. 20:38 Ubuntu membership via the DMB, or otherwise? 20:38 Otherwise - via one of the regional boards. 20:39 ok 20:39 Because it'd be a "signifcant and sustained contribution to Ubuntu" to be doing C. 20:39 one question that comes to mind: do we expect them to have agreed to the Ubuntu Code of Conduct, which is a condition of membership? 20:39 I'm not sure I understand the relevance of anything being DMB-approved here. What would their acceptance criteria for an application be? 20:40 I don't think it is relevant to be DMB approved, I just don't have much visibility on the regional board process 20:40 That's a good point. 20:40 Maybe CoC acceptance should be a hard requirement. 20:40 +1 20:40 What if we added that to C? 20:40 So Ubuntu membership as a requirement then? This would mean CoC being signed and having presence in the Ubuntu ecosystem 20:40 I would feel more strongly about that if the Ubuntu CoC had been refreshed in the past 15 years :) 20:41 It's a good starting point though. 20:41 I know it's me that raised the question, but I'm +0 and will go with the group's consensus on CoC 20:41 adhering to the CoC, and the fact that the CoC is outdated are two different things 20:42 So people who can push snaps to users who receive them by default must have signed the CoC, and their work qualifies under the work required for Ubuntu membership. But no further requirement (ie. no DMB involvement). 20:42 +1, sounds good I think? 20:42 Let me add that quickly. 20:42 +1 from me 20:44 Lines 48-50 added. 20:44 Is that consistent with everyone's agreement? 20:44 yep 20:44 We might need to ask the CC to ratify the membership bit but I don't see a problem with that happening. 20:45 sorry, going to quibble a bit on the mechanics of the snap store - "people who can upload the package", or "people who publish to the Ubuntu channels"? 20:45 "People who publish to the Ubuntu channels" is what I meant. 20:45 ok 20:45 So if you're at Mozilla publishing to edge, you don't need to care. 20:45 right, precisely the case I was thinking of 20:47 I've amended it in a hurry; I'll make the wording pretty when I write up the draft properly. 20:47 If we're done with C? 20:47 yes please 20:47 yes 20:47 Any comments on D? I assume this is uncontroversial and we can move on? 20:47 yes 20:47 no comment on D 20:47 On E, I think I've failed to define it clearly, and it's probably better to focus on the others for now. 20:48 agreed 20:48 The telemetry/phone-home example does bother me a little, but we can come back to it. Notably we can always patch thanks to requirement B, and I think that's an example of the catch-all ability the TB will be able to have thanks to B, which means that we can defer consideration of that type of thing. 20:49 F and F2 are also I think basically uncontroversial? 20:50 I would like for F to simply say launchpad instead of hinting that there's a process to get a build farm trusted 20:50 I tend to agree 20:51 +1 20:51 I'm sort of +0, but I suppose it doesn't matter then :) 20:52 I've added a comment 20:52 And I'll draft accordingly. 20:52 Anything else on F or F2? 20:53 nothing from em 20:53 me 20:53 not form me 20:53 *from 20:53 All good 20:53 well - do people agree with my comment on f2? 20:53 More or less. 20:53 that would be ideal 20:53 ok 20:53 but I'm ok with an alternative 20:53 I don't know about the binary itself, because that seems circular. 20:53 It's not a hard requirement for me, but certainly would be a nice touch 20:53 as long as it's something documented 20:53 You can't do that from a deb binary for example. 20:54 the deb control file says the source package name 20:54 and snap meta.yaml has fields for this sort of thing I believe 20:54 I think you can in a sense, there's the copyright file as well which states the source 20:54 we just need to insist they be used 20:55 oh, if there are fields, then yes, they should be used 20:55 I think what you're saying is: if I have a snap binary, the machinery that supplied it (store/Launchpad) must be able to map it back and provide the build information/logs with the metadata I have 20:55 that sould be a requirement 20:55 If so, then +1 20:55 (to some reasonable time limit) 20:56 mdeslaur: I mean, if there AREN'T fields then that's a gap we should address with the snapd/snapcraft teams - my understanding is that it's specified but I wouldn't be able to tell you the field name off hand 20:56 yeah 20:57 an end user should be able to find the build information/logs 20:58 We're nearly out of time. 20:58 G is dealt with by having been adjusted and adopted into C. 20:58 we only have H left 20:58 I'm not sure what to do about H. 20:58 H was about trust anchors of the third-party repository 20:59 i.e. no we won't trust the flatpak store which has a trust anchor owned by a different entity 20:59 (flathub) 20:59 I don't want pre-seeded snaps to come from a store that we don't own the trust of 21:00 Ah. 21:00 if we scope this to "seeded snaps" then H may be unneccessary in practice because this policy is encoded in the snapd binary 21:00 So F is currently "package is built on a build farm that is trusted by the Ubuntu project" 21:00 What if that's changed to "package is built *and published from* infrastructure that is trusted by the Ubuntu project"? 21:01 yeah, that could be added to H 21:01 And s/Ubuntu project/Launchpad and Snap Store/ based on earlier discussion? 21:01 just as I think it's best to be explicit that Launchpad is the build farm we trust, I think it's best to be explicit about our policies as a community about what publishing infrastructure we trust 21:01 sorry, I mean that could be added to F 21:02 but I tend to agree vorlon, those are two different things 21:02 we are at time 21:02 how do we want to proceed? 21:03 ok I see it's being added to F (by rbasak I presume) 21:03 I tried that but if you disagree we can take it out 21:03 Maybe defer further discussion to the next meeting? We've made plenty of progress and I have a lot of drafting to do. 21:03 ok 21:03 vorlon: so specifying launchpad and snap store would be ok for you? 21:03 ok, we can defer 21:04 mdeslaur: yes 21:04 #topic scan the mailing list archive for anything we missed 21:04 There is a private thread that needs attention 21:04 #link https://lists.ubuntu.com/archives/technical-board/2022-January/thread.html 21:04 nothing there - but what rbasak says 21:04 (on my todo list for this afternoon) 21:04 OK thanks. I'll wait for vorlon on that one then. 21:04 #topic check up on community bugs 21:05 #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard 21:05 nothing to see there 21:05 #topic Select a chair for the next meeting 21:05 cyphermox gets to keep first billing, with sil2100 as backup 21:05 sil2100: provided that's ok / you have no conflicts 21:06 * xnox ponders what i can do to stop being pinged by TB every time they have a meeting 21:06 change your nick 21:06 hahahaa 21:07 #agreed next meeting 2022-02-08 20:00 London time, chair: cyphermox, backup: sil2100 21:07 AGREED: next meeting 2022-02-08 20:00 London time, chair: cyphermox, backup: sil2100 21:07 #topic aob 21:07 just in case - anything? 21:07 *crickets* 21:07 #endmeeting