19:02 #startmeeting Technical Board 19:02 Meeting started at 19:02:12 UTC. The chair is rbasak. Information about MeetBot at https://wiki.ubuntu.com/meetingology 19:02 Available commands: action, commands, idea, info, link, nick 19:02 #topic Action Items 19:02 * rbasak seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:02 I've seen some text. Is that ready? 19:04 hum 19:05 do we need Ken to reply to your comments? 19:05 There are some comments, and also I've seen a suggestion from timhm to drop the current use of the branches that auto-close. 19:05 I pinged timhm but he's only back from PTO today. 19:05 fwiw the text there is different than the original rationale for the ubuntu-YY.MM tracks 19:05 I was going to ping Ken today but I found that he's out for a few days too 19:06 > The complete channel name can be structured as three distinct parts separated by slashes: 19:06 > // 19:06 i.e. they weren't intended to be a committment to "bugfix+security only changes", they were only intended to be an escape hatch if there was a per-release regression due to integration issues 19:06 Currently I believe we're using *branch* 19:06 Which autocloses after 30 days 19:06 ah 19:07 "Requirement B: Ubuntu developers will be able to override and patch the package" 19:07 yes, sorry, I assumed this was referring to the stuff we were currently using and second-guessed myself on track vs branch :) 19:07 That would be fulfilled by the current use of the branch I think. 19:07 And is sort of similar to the escape hatch rationale you mention but not quite the same. 19:07 the current use is to set our snap to follow stable/ubuntu- right? 19:07 right 19:07 so that means following stable 19:08 but what we would like is rather to follow a serie specific track 19:08 "we would like" - who would like that and why? 19:09 like for GNOME 45 we should set mantic to follow 45/ stable 19:09 45/stable 19:09 well, if the goal is to have a behaviour similar to what we have today with debs 19:09 I think that would be fine 19:10 following latest/stable would mean mantic users would get GNOME 46 updates when those are flagged stable 19:10 But it would need to be 45/stable/ubuntu-24.04 or similar 19:10 the reason I suggested tracks rather than branches is to avoid the issue of branches auto-closing - and the reason I put in the bug/security fixes only is to try and have the same expectation for snaps as debs from an end-users perspective 19:10 So using like we already do, but also adding . 19:11 amurray: so I think the pushback from the store admins would be that this overloads the purpose of tracks and the idea that snaps are supposed to be distro-agnostic. 19:11 AIUI, there was a similar resistance to using branches in this way, but it did end up happening. 19:11 There's another important behaviour to keep in mind here. 19:12 snapd can "track" firefox latest/stable/ubuntu-22.04 for example, but if that doesn't exist, then it just falls back to use "latest/stable" instead. 19:12 45 is not an Ubuntu version, of course. If we are using tracks based on the versioning of the application upstream, that will cause more work on the Ubuntu side to keep track of the tracks; if we wanted consistency on the Ubuntu side to always use tracks such as ubuntu-23.10/stable (the current suggested text?) that puts more work on the snap publisher 19:12 Replace "latest" with a track if you like. 19:12 So we don't usually have to publish to the branch, so auto-closing isn't much of a concern in practice. 19:13 If we used the escape hatch, _only then_ would we need to make sure we keep republishing within 30 days, or see about changing that feature. 19:13 fwiw firefox has been using the branches 19:13 as has subiquity 19:13 On this machine I have: 19:13 tracking: latest/stable/ubuntu-22.04 19:13 just in case anyone thought this was a vestigial feature 19:14 Oh yes and my revno is different from the channels that are publicly visible. 19:14 yep but I thought there was pushback from the desktop team that they found it onerous that the branches autoclose 19:14 To make progress with the doc in general, I suggest that we document what we're currently doing, and make sure that before we change what we're doing everyone involved reaches consensus first? 19:15 it sounds like we are choosing between two problems - either we use branches and that puts the burden on the publisher to keep publishing else they auto-close - or we use tracks which gets pushback from the store team..? 19:15 amurray: well, I think that's a valid objection and maybe worth revisiting with the store team? but for this discussion, wrt track naming I'll point out that a firefox upstream version would not be suitable for the track if you wanted it to be different for 22.04 and 23.04 19:16 why would the store team push back on the use of tracks? 19:17 AIUI, they don't want Ubuntu-specific tracks. The store is supposed to be distro-agnostic, so the tracks should be what makes sense to the upstream. 19:17 ok 19:17 then tracks are unsuitable for firefox 19:18 because the differences between the snaps on the different branches right now are about base+content snap, not upstream version branches 19:18 I don't mind how this is implemented, but I think that our base requirements are reasonable and the snap ecosystem needs to be able to figure out how to support them :-/ 19:19 the store team doesn't want to accomodate branches that don't auto-close, but nothing says that the publishers can't set up timers to auto-refresh those branches and keep them open 19:20 but, as rbasak points out, the implementation is not really a TB question 19:21 wrt this point on the agenda, it doesn't seem we're ready to close anything out? 19:21 Agreed. 19:21 But can we agree on next steps? 19:21 same 19:21 I had a suggestion on that bove 19:22 "document what we're doing" - +1 from me 19:22 +1 19:22 Could someone who understands exactly what we're doing please take that action? :) 19:23 I think seb128 is best positioned 19:23 alright :p 19:23 OK so let's carry the action 19:23 #action seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:23 * meetingology seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:23 * rbasak rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 19:24 I'll carry this over again 19:24 #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 19:24 * meetingology rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 19:24 (I'm not aware for any reason for this to be a priority right now) 19:24 * rbasak rbasak to follow up on finding consensus on question of test plans for third party apps 19:24 Hmm. I don't remember this. 19:25 IIRC there was a question about what should be required wrt test plans for seeded snaps, vs. the MIR requirements for autopkgtests 19:26 Just found the logs 19:26 OK looks like I knew the details once, so I'll carry that over and I don't think I'm blocked 19:26 #action rbasak to follow up on finding consensus on question of test plans for third party apps 19:26 * meetingology rbasak to follow up on finding consensus on question of test plans for third party apps 19:26 * rbasak rbasak to restructure the third-party repo doc to make the status clearer 19:26 This one's done I think? 19:26 * rbasak rbasak to open wider discussion on third-party repo policy 19:27 I started writing up a post for a call for wider discussion and feedback. 19:27 I feel a little blocked on a comment from Ken in the doc. I intend to follow up with him his week or next week after he's back from PTO. 19:27 #action rbasak to open wider discussion on third-party repo policy 19:27 * meetingology rbasak to open wider discussion on third-party repo policy 19:27 * rbasak seb128 to follow up with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:28 carry over please 19:28 #action seb128 to follow up with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:28 * meetingology seb128 to follow up with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:28 #topic Packages in the archive that download and run software from the Internet, and third-party repository requirements 19:28 (vorlon) 19:28 hi 19:29 the reason I put this on the agenda was that I happened to just notice that the lutris package in multiverse downloads software from possibly arbitrary locations on the Internet to be run 19:29 and I think that's bad and was going to dig into it to see just how bad and whether it should be thrown out of the archive 19:30 and then I realized I didn't have a written policy on this stuff that I could point to 19:30 I'm reminded of flashplugin-downloader or whatever it was called 19:30 Also torbrowser-launcher 19:30 flashplugin-downloader at least had the constraints that it would only download files with known hashes that were embedded in the packaging 19:30 That one's in universe. 19:31 the fact that it downloaded at install time rather than shipping in the package was a concession to redistribution constraints 19:31 hmm is this a slippery slope? we also have say emacs which can be configured to download emacs lisp packages from arbitrary locations 19:31 (just as an example) 19:31 I was going to point at wget :-P 19:31 heh 19:31 or you can download anything to install from a webbrowser... 19:32 So, where's the line? 19:32 Does being in multiverse make it OK? 19:34 does lutris do any sandboxing internally? perhaps if it did then that would lessen the risk here 19:34 well lutris is effectively a package shipping a "store" for third-party games from the Internet 19:35 Sounds like the flatpak package :-P 19:35 (although it doesn't default to a store I don't think!) 19:35 So snapd 19:35 well, right, and clearly we have expectations about what the snapd package should present as a store :) 19:36 One could argue that a user understands that installing lutris opts them in to a specific store 19:36 the bit that irked me was actually watching it download a mame tarball from the Internet when we have mame as a deb 19:37 rbasak: I don't think our users should be expected to assess the security design of every store someone puts in the Debian or Ubuntu archive as a deb and that we should have some common guidelines 19:38 does lutris have cryptographic verification of the games it downloads from the Internet? is that based on ssl or on some sort of signing of a store payload? who manages that? is there sandboxing? etc 19:38 lutris is synced from Debian though? 19:38 common guidelines sound reasonable 19:39 So while I understand your concern and would like to see improvement there, I'm not sure we could really be effective unless Debian is also doing it, so it seems like we would need consensus in Debian 19:39 OTOH the other stuff involving third party requierements are mostly Ubuntu-specific differences 19:40 Like we might as well document "if Debian do it then it's acceptable for Ubuntu by default because autosync" in our doc 19:40 well even if there is a policy we'd likely be playing whack-a-mole for a while in either Debian or Ubuntu 19:40 I would still like to see some documented principles of what we expect from packages in the Ubuntu archive 19:40 I have no objection to having the TB endorse something like that. 19:41 (btw lutris actually completely failed to download and install the game I was trying to get running on my kid's system, and I wound up grabbing a zip file of the DOS program and running it directly under dosbox :P) 19:41 vorlon: would you like an action to write some guidelines? 19:41 rbasak: sounds like you're suggesting .. ^ that :) 19:41 yes 19:42 #action vorlon to write up draft guidelines for packages in the archive that download from the Internet 19:42 * meetingology vorlon to write up draft guidelines for packages in the archive that download from the Internet 19:42 ^ that wording is deliberately open. You can figure out how to define the scope when you write it up :) 19:42 Any further discussion on this topic? 19:43 fwiw I think there's other historical precedent of e.g. disabling browser plugin stores by default in browsers 19:43 or of disabling vendor auto-update mechanisms 19:43 This will be quite slippery to define I think. 19:43 all related :) 19:43 yep. challenge accepted, thanks 19:43 #topic Scan the mailing list archive for anything we missed (standing item) 19:44 #info No recent ML posts 19:44 #topic Check up on community bugs and techboard bugs 19:44 #info No new bugs; existing bugs are all being handled through existing action items 19:45 #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) 19:45 #info Next chair will be seb128 with vorlon as backpu 19:45 #indo 19:45 #undo 19:45 Removing item from minutes: INFO 19:45 #info Next chair will be seb128 with vorlon as backup 19:45 ack 19:45 * vorlon nods 19:45 #topic AOB 19:46 Anything else from anyone? 19:46 nothing here 19:46 #endmeeting