20:04 <vorlon> #startmeeting
20:04 <meetingology> Meeting started at 20:04:33 UTC.  The chair is vorlon.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
20:04 <rbasak> (just because you're next on the list)
20:04 <meetingology> Available commands: action, commands, idea, info, link, nick
20:04 <vorlon> [topic] apologies
20:04 <vorlon> #topic apologies
20:05 <vorlon> nothing seen on the mailing list
20:05 <vorlon> #topic Action review
20:05 * vorlon formal ratification of third party seeded snap security policy, depends on: (rbasak, 19:06)
20:05 <vorlon> I don't understand this dependency statement
20:05 <rbasak> It relies on the following line
20:05 <vorlon> 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 <vorlon> carry-over
20:06 * vorlon vorlon to reply to seeded snap upload permissions question on list
20:06 <vorlon> 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 <sil2100> Yes
20:06 <rbasak> Sort of mixed up in all of this is to make progress on the requirements pad
20:06 <vorlon> yes it's done? :)
20:06 <rbasak> (previous item)
20:06 * vorlon nods
20:06 <sil2100> 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 <sil2100> I was able to get some information
20:07 <vorlon> great
20:07 <vorlon> do you need anything more from us?
20:07 <sil2100> The things I was previously thinking about was: who has access to the OEM archive (upload rights) and what processes they follow
20:07 <sil2100> 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 <sil2100> https://launchpad.net/~oem-archive/+members
20:08 <vorlon> fwiw, I raised an eyebrow at the response on ubuntu-devel to your recent email
20:08 <vorlon> which says that OEM builds default to release upgrades being disabled
20:08 <mdeslaur> o_O
20:08 <sil2100> Yeah, I don't remember knowing about that!
20:08 <sil2100> First time I hear it
20:08 <vorlon> I talked with the Desktop Team about it this morning, they didn't know either
20:08 <rbasak> We did wonder what rules the OEM builds followed. Turns out they exist without any TB input or approval.
20:09 <rbasak> So it seems like exactly how they behave hasn't really ever been reviewed.
20:09 <rbasak> (by anyone wearing an Ubuntu hat)
20:09 <sil2100> 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 <rbasak> And perhaps that needs to happen
20:10 <rbasak> I appreciate the progress you're making on this sil2100!
20:10 <sil2100> 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 <sil2100> But sadly, I didn't wrap my head around it yet
20:10 <sil2100> For the record, the OEM archive draft is in progress here: https://wiki.ubuntu.com/OEMArchive
20:10 <sil2100> But no progress yet since last week!
20:11 <vorlon> ok, thanks for the summary/update
20:11 <sil2100> Let's carry it over for now, but I think at least there's progress
20:11 <vorlon> #topic ACTION: all members to continue discussion at https://pad.ubuntu.com/third-party-repository-requirements
20:11 <vorlon> how's this going? :)
20:12 <rbasak> I'd like to run through where we are per proposed requirement please.
20:12 <vorlon> ok
20:12 <rbasak> 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 <rbasak> Prop. req. A: I provided draft wording as we discussed previously. Does vorlon have feedback on that please?
20:14 <rbasak> 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 <vorlon> 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 <rbasak> Yeah I regret using the pad. If everyone's fine with it I can migrate to Google Docs.
20:15 <rbasak> (but cyphermox isn't here)
20:15 <mdeslaur> 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 <vorlon> I don't think you need to mention channel there, "the snap presented to Ubuntu users" encompasses this
20:15 <mdeslaur> s/up to/up to us/
20:15 <rbasak> vorlon: removed, thanks
20:16 <vorlon> rbasak: otherwise I think it looks good, captures the intent, and of course we know up front the browser gets an exception
20:16 <rbasak> mdeslaur: could you add yourself to "Support:" in that case please? Or do I misunderstand?
20:17 <rbasak> And same to vorlon :)
20:17 <vorlon> ack
20:17 <vorlon> as it happens I was just looking at seeded snaps on the focal desktop today, due to fixing a livecd-rootfs bug
20:17 <mdeslaur> ok, added
20:17 <vorlon> would it be worth talking about what's currently there?
20:17 <mdeslaur> (and look, my colour changed)
20:18 <rbasak> vorlon: you mean in terms of which packages will need an exception?
20:18 <vorlon> yes
20:19 <vorlon> particularly as, uh, some of the dependency snaps have changed since 20.04 release
20:19 <rbasak> 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 <rbasak> sil2100: your opinion please on the status quo?
20:20 <sil2100> Yeah, a discussion with seeded snap owners might be helpful here
20:20 <vorlon> 20.04.3 shipped with gnome-3-34-1804; 20.04 daily now has gnome-3-38-2004
20:20 <vorlon> fwiw
20:20 <vorlon> so I'm sure gnome-3-34-1804 is very stable :P
20:20 <sil2100> 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 <rbasak> 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 <vorlon> ack
20:21 <rbasak> sil2100: but they don't know it's a snap. It's there by default (for example).
20:21 <sil2100> 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 <rbasak> And if they want to opt-in to always-update, then that's usually available to opt-in to.
20:22 <sil2100> Ok, added my +1 on that then
20:22 <rbasak> Thanks
20:22 <sil2100> True!
20:22 <rbasak> So prop. req. B next
20:22 <sil2100> Valid point, they can just switch tracks then
20:22 <rbasak> I think we have general support, so maybe this is just an action for me to draft the wording for further discussion.
20:22 <rbasak> Any other comments?
20:23 <rbasak> (on how to proceed)
20:23 <sil2100> +1
20:23 <rbasak> And same for C and D.
20:23 <sil2100> This is something that was bothering us at the release team since ages, requirement B
20:24 <sil2100> 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 <vorlon> sil2100: your 'support' on B has a footnote though?
20:26 <sil2100> I think I generally agree, I think my footnote was just about having power for selected subsets of users
20:27 <vorlon> so do you want language amended / fleshed out here to capture this?
20:28 <mdeslaur> 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 <sil2100> 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 <sil2100> Tracks/branches
20:29 <sil2100> But maybe that's overcomplicating things, as this would require changes to the store possibly
20:29 <vorlon> well - to be clear, my assumption is that we are ONLY guaranteed to have rights to override the per-Ubuntu-release channels
20:29 <rbasak> 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 <mdeslaur> ok
20:29 <rbasak> (and then we can approve specific implementations later)
20:30 <vorlon> 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 <mdeslaur> right
20:32 <vorlon> 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 <rbasak> Any further discussion on B?
20:33 <mdeslaur> ok, anything else about B?
20:33 <vorlon> 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 <sil2100> All good here now
20:34 <rbasak> 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 <sil2100> 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 <vorlon> I'm good w/ C, D
20:36 <mdeslaur> I'm good with C as long as security updates and testing is mentioned
20:36 <sil2100> Yeah, I think the only comment was to maybe include req G as part of C?
20:37 <rbasak> I'm not sure I feel the need to require G.
20:37 <rbasak> How do others feel about this?
20:37 <mdeslaur> as long as testing is mentioned in C, we can get rid of G
20:38 <rbasak> Ubuntu membership would probably be granted to anyone consistently maintaining a package and meeting our requirements anyway, I think? Ie. fulfilling C.
20:38 <vorlon> Ubuntu membership via the DMB, or otherwise?
20:38 <rbasak> Otherwise - via one of the regional boards.
20:39 <vorlon> ok
20:39 <rbasak> Because it'd be a "signifcant and sustained contribution to Ubuntu" to be doing C.
20:39 <vorlon> 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 <rbasak> 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 <vorlon> 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 <rbasak> That's a good point.
20:40 <rbasak> Maybe CoC acceptance should be a hard requirement.
20:40 <mdeslaur> +1
20:40 <rbasak> What if we added that to C?
20:40 <sil2100> So Ubuntu membership as a requirement then? This would mean CoC being signed and having presence in the Ubuntu ecosystem
20:40 <vorlon> I would feel more strongly about that if the Ubuntu CoC had been refreshed in the past 15 years :)
20:41 <rbasak> It's a good starting point though.
20:41 <vorlon> 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 <mdeslaur> adhering to the CoC, and the fact that the CoC is outdated are two different things
20:42 <rbasak> 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 <sil2100> +1, sounds good I think?
20:42 <rbasak> Let me add that quickly.
20:42 <mdeslaur> +1 from me
20:44 <rbasak> Lines 48-50 added.
20:44 <rbasak> Is that consistent with everyone's agreement?
20:44 <mdeslaur> yep
20:44 <rbasak> We might need to ask the CC to ratify the membership bit but I don't see a problem with that happening.
20:45 <vorlon> 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 <rbasak> "People who publish to the Ubuntu channels" is what I meant.
20:45 <vorlon> ok
20:45 <rbasak> So if you're at Mozilla publishing to edge, you don't need to care.
20:45 <vorlon> right, precisely the case I was thinking of
20:47 <rbasak> I've amended it in a hurry; I'll make the wording pretty when I write up the draft properly.
20:47 <rbasak> If we're done with C?
20:47 <vorlon> yes please
20:47 <mdeslaur> yes
20:47 <rbasak> Any comments on D? I assume this is uncontroversial and we can move on?
20:47 <vorlon> yes
20:47 <mdeslaur> no comment on D
20:47 <rbasak> 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 <mdeslaur> agreed
20:48 <rbasak> 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 <rbasak> F and F2 are also I think basically uncontroversial?
20:50 <mdeslaur> 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 <vorlon> I tend to agree
20:51 <sil2100> +1
20:51 <rbasak> I'm sort of +0, but I suppose it doesn't matter then :)
20:52 <rbasak> I've added a comment
20:52 <rbasak> And I'll draft accordingly.
20:52 <rbasak> Anything else on F or F2?
20:53 <vorlon> nothing from em
20:53 <vorlon> me
20:53 <mdeslaur> not form me
20:53 <mdeslaur> *from
20:53 <sil2100> All good
20:53 <vorlon> well - do people agree with my comment on f2?
20:53 <rbasak> More or less.
20:53 <mdeslaur> that would be ideal
20:53 <vorlon> ok
20:53 <mdeslaur> but I'm ok with an alternative
20:53 <rbasak> I don't know about the binary itself, because that seems circular.
20:53 <sil2100> It's not a hard requirement for me, but certainly would be a nice touch
20:53 <mdeslaur> as long as it's something documented
20:53 <rbasak> You can't do that from a deb binary for example.
20:54 <vorlon> the deb control file says the source package name
20:54 <vorlon> and snap meta.yaml has fields for this sort of thing I believe
20:54 <sil2100> I think you can in a sense, there's the copyright file as well which states the source
20:54 <vorlon> we just need to insist they be used
20:55 <mdeslaur> oh, if there are fields, then yes, they should be used
20:55 <rbasak> 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 <mdeslaur> that sould be a requirement
20:55 <rbasak> If so, then +1
20:55 <rbasak> (to some reasonable time limit)
20:56 <vorlon> 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 <mdeslaur> yeah
20:57 <mdeslaur> an end user should be able to find the build information/logs
20:58 <rbasak> We're nearly out of time.
20:58 <rbasak> G is dealt with by having been adjusted and adopted into C.
20:58 <mdeslaur> we only have H left
20:58 <rbasak> I'm not sure what to do about H.
20:58 <vorlon> H was about trust anchors of the third-party repository
20:59 <vorlon> i.e. no we won't trust the flatpak store which has a trust anchor owned by a different entity
20:59 <vorlon> (flathub)
20:59 <mdeslaur> I don't want pre-seeded snaps to come from a store that we don't own the trust of
21:00 <rbasak> Ah.
21:00 <vorlon> 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 <rbasak> So F is currently "package is built on a build farm that is trusted by the Ubuntu project"
21:00 <rbasak> What if that's changed to "package is built *and published from* infrastructure that is trusted by the Ubuntu project"?
21:01 <mdeslaur> yeah, that could be added to H
21:01 <rbasak> And s/Ubuntu project/Launchpad and Snap Store/ based on earlier discussion?
21:01 <vorlon> 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 <mdeslaur> sorry, I mean that could be added to F
21:02 <mdeslaur> but I tend to agree vorlon, those are two different things
21:02 <vorlon> we are at time
21:02 <vorlon> how do we want to proceed?
21:03 <mdeslaur> ok I see it's being added to F (by rbasak I presume)
21:03 <rbasak> I tried that but if you disagree we can take it out
21:03 <rbasak> 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 <vorlon> ok
21:03 <mdeslaur> vorlon: so specifying launchpad and snap store would be ok for you?
21:03 <mdeslaur> ok, we can defer
21:04 <vorlon> mdeslaur: yes
21:04 <vorlon> #topic scan the mailing list archive for anything we missed
21:04 <rbasak> There is a private thread that needs attention
21:04 <vorlon> #link https://lists.ubuntu.com/archives/technical-board/2022-January/thread.html
21:04 <vorlon> nothing there - but what rbasak says
21:04 <vorlon> (on my todo list for this afternoon)
21:04 <rbasak> OK thanks. I'll wait for vorlon on that one then.
21:04 <vorlon> #topic check up on community bugs
21:05 <vorlon> #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard
21:05 <vorlon> nothing to see there
21:05 <vorlon> #topic Select a chair for the next meeting
21:05 <vorlon> cyphermox gets to keep first billing, with sil2100 as backup
21:05 <vorlon> 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 <mdeslaur> change your nick
21:06 <vorlon> hahahaa
21:07 <vorlon> #agreed next meeting 2022-02-08 20:00 London time, chair: cyphermox, backup: sil2100
21:07 <meetingology> AGREED: next meeting 2022-02-08 20:00 London time, chair: cyphermox, backup: sil2100
21:07 <vorlon> #topic aob
21:07 <vorlon> just in case - anything?
21:07 <mdeslaur> *crickets*
21:07 <vorlon> #endmeeting