20:08 #startmeeting Ubuntu Technical Board 20:08 Meeting started at 20:08:44 UTC. The chair is teward. Information about MeetBot at https://wiki.ubuntu.com/meetingology 20:08 hey, sorry for being late, as usually it's a busy time of the day 20:08 Available commands: action, commands, idea, info, link, nick 20:09 seb128: no worries 20:09 today's the date and time set for the first 2026 meeting of the Technical Board 20:09 #topic Action Review 20:09 - teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over) 20:09 still carried over, CC has been a little slow on this but i'll rally them up again on this 20:09 #action teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over) 20:09 * meetingology teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over) 20:10 - Provide feedback in "RFC: SRU Exception for transitional hardware enablements (tHWE)" thread once additional data is made available (waiting on PE team data) 20:10 did we ever get data back from the team on this? 20:10 I just emailed the list about that. 20:10 i see robie emailed about this just a few minutes ago 20:10 I've not heard anything. 20:10 i'll talk to frank before the next TB meeting 20:10 ah then my email client is being slow. at least we're on it and hunting it still 20:10 #action Provide feedback in "RFC: SRU Exception for transitional hardware enablements (tHWE)" thread once additional data is made available (waiting on PE team data) 20:10 * meetingology Provide feedback in "RFC: SRU Exception for transitional hardware enablements (tHWE)" thread once additional data is made available (waiting on PE team data) 20:11 right, onto the topics here on the agenda 20:11 #topic snapd SRU exception request 20:11 #link https://lists.ubuntu.com/archives/technical-board/2025-September/003050.html 20:11 #link https://code.launchpad.net/~ernestl/sru-docs/+git/sru-docs/+merge/493382 20:11 i still haven't looked at this properly :( 20:11 I'd like to hear what the TB think about the re-exec behaviour. 20:14 I'm not entirely sure what to think about the re-exec behavior. Is this new behavior or has it always been present? 20:14 part of me wants to ask Security what they think about that behavior 20:14 It was added at some point without consultation with anyone on the Ubuntu side, AIUI 20:15 so in principle re-exec means that the snapd developers do not have to SRU snapd updates, if an update is pushed to the stable channel it would in effect be delivered to users without having to wait for SRU / pass the validation steps implied by the SRU process 20:15 I though that it was quite an old behaviour, do you know when it was added? 20:15 A long time ago, yes. 20:16 in effect i don't know how much difference this makes because snapd updates always do get SRUed and i don't know that the validation that the ubuntu SRU process involves adds a lot to the amount the snapd developers already do for a stable update (although i guess there is a difference in who is responsible) 20:16 It came up recently because it turns out that the snapd team had stopped following the documented SRU process years ago too, but nobody noticed until a newer SRU team tried to process a snapd SRU with "why haven't you followed the documented steps" and the response was "that's not the docs we use" 20:17 It does seem like it makes the SRU process somewhat pointless in the case of snapd. 20:17 it is certainly the case that the currently documented sru exception text is wildly out of date 20:17 Somewhat pointless to do both, anyway. 20:17 If we allow re-exec, then it would follow to make the SRU process much "thinner" - check for collisions in interactions with other packages, and that's it really. 20:18 I would be in favor of that 20:18 But then it would seem odd to take snapd updates out of the hands of Ubuntu entirely. 20:18 I think rolling for snapd makes sense, it needs to get updated or you will end up with systemd where snapd isn't able to handle the snaps currently in the store that use new features 20:19 Especially as snapd, AFAIK, is massively beyond the scope of Ubuntu snap packaging nowadays. 20:19 rbasak: how does that differ from the existing process of snaps being updated independently of Ubuntu SRU processes? Just thinking out loud here. 20:19 i'm not sure re-exec is really the part to focus on 20:19 teward: not much different from flatpak really there. 20:19 i'm not sure re-exec is the part to focus on here either., 20:19 teward: or pip, for that matter 20:19 question 1 is "do we want new snapd versions to be available to users of stable releases" 20:20 i think the answer to this has to be yes, or there's not really any point to the whole project 20:20 I think the answer to that is "yes" 20:20 question 2 is then, do we still want people with ubuntu hats to be involved in gating these updates? 20:20 The real question is what, if any, gating should Ubuntu do for snapd updates for quality, like it does for any other package it ships 20:21 The principles from the third party repo reqs doc matter here I think 20:21 How do those principles apply to snapd itself? 20:23 hum 20:24 principles 3-8 are clearly fine for snapd 20:25 principle 1 is IMO ok too (i know from waiting for snapd releases that a great deal of regression testing happens before a snapd release hits stable) 20:25 I can't find it in the docs. Link, please? 20:26 The TOC of the docs doesn't make sense to me any more :-( 20:26 https://documentation.ubuntu.com/project/tech-board/3rd-party-software-sources/ 20:26 i think it's this? https://documentation.ubuntu.com/project/tech-board/3rd-party-software-sources/ 20:26 Thanks 20:26 principle 2 states: "Outside debs shipped through the primary archive, it is not expected that this mechanism will be invoked, but the mechanism must exist for use by Ubuntu developers as a last resort." 20:27 "Principle 2: Ubuntu developers can override and patch packages" is an interesting one. ubuntu developers can always upload a snapd with a newer version than the snapd snap, which will inhibit re-exec 20:27 So maybe we treat snapd as if it's entirely a snap 20:27 Given that it re-execs, it effectively is 20:27 or upload a snapd with re-exec patched out, or whatever 20:27 And if principle 2 is maintained by the behaviour you describe, then fine 20:28 If that's where this takes us, then maybe that'd be easier for everyone? 20:29 yes i think so 20:29 as you said up there ^^ somewhere the SRU review is still needed to review packaging, i.e. make sure that installing the snapd deb doesn't mess up other things 20:31 Then the TB would say: a) re-exec behaviour is OK, fits the principles; b) principle 2 must be maintained, the mechanism we think works is fine assuming it does; c) leave it to the SRU team to figure out the details on how to review snapd (deb) SRUs to ensure bad interactions with other packages don't happen, but otherwise, no expectation of QA mandated from the TB since that's delegated to 20:31 upstream. 20:31 I think i still have one small confusion... 20:31 the SRU exception applies to .deb. Are they still planning to update, etc. the .deb of snapd as well as the snap, or are they moving entirely to the snap? 20:32 I'd like to mull over this in case I missed something, but unless some other point is made, maybe let's float that with the SRU team as a proposal? 20:32 teward: they do update the .deb still, but the .deb re-execs to the snap subject to some criteria (version based IIUC) 20:33 the question of whether we need to SRU each deb is interesting i guess. i think from the TB pov that's something the snapd developers can decide 20:34 (we'd probably want to SRU a new version before each point release so the deb is new on the ISO? there are details about that i forget) 20:34 rbasak: +1 20:34 wouldn't the determinatino of whether to SRU each deb fall on the SRU and Release teams, not TB? 20:34 just, you know, thinking out loud 20:34 i think this means that Ernest's MP can probably be much simplified but i still need to, you know, actually read it 20:34 The SRU team would review each proposed snapd deb SRU, yes. 20:35 But they wouldn't be deciding if it's appropriate to SRU the snapd deb at all. That should be decided between the TB and SRU team now, for all future snapd SRUs, so the question doesn't need to be asked every time. With conditions if we wish. 20:35 Oh, one open thing is the scope of snapd 20:36 I get the impression it does more than just snap packaging nowadays. 20:37 And another thing comes to mind. The policy was written with the assumption that packages being installed were generally isolated from each other, and didn't interact with the system much. snapd of course is the complete opposite. 20:37 For example, if snapd were to grow an "I can mess with your bootloader" feature, maybe that's something that shouldn't be SRUd (or re-exec permitted for) without review. 20:38 well it does have that stuff for TPM-FDE installs, but not for classic 20:40 This reminds me of Google's Play Services somewhat 20:40 If more functionality gets moved into there with the above proposal, then where are we with managing how Ubuntu works at all? 20:40 it is not completely different for sure 20:41 maybe we should discuss this aspect more next time. 20:42 For stable releases, perhaps the implied exception to principle 1 should apply to managing user-installed snaps only. 20:42 But even with that, I'm not sure about how this works with future changes and scope creep 20:43 because there is a future in which the majority of laptops running ubuntu are running core desktop in some shape or form and we should think about how that works from a governance pov 20:43 Is it safe for me to assume this warrants further discussion beyond just this one meeting? I am not comfortable voting on this SRU exception revision until these remaining issues are figured out, because they're completely relevant and will affect other things (by precedent alone) going forward. 20:44 and we have only about 17 minutes left and one other agenda item 20:44 yes 20:44 (though the other item might not be as time important) 20:44 Yeah I think we need further discussion another time 20:44 I'll update the SRU team with the conversation but I'm not sure it's a concrete proposal any more, but just an idea now 20:44 right, we aren't going to resolve those questions today/in the remaining minutes 20:44 #info snapd SRU exception request needs further discussion, remains as an active agenda item for discussion 20:45 i think *in practice* the chance of snapd growing code to mess with the boot process on a regular old install of 24.04 (or even 26.04) is 0% but we are talking about policy 20:45 rbasak: i don't think it's a concrete proposal anymore as it stands, because of the wildly different concerns that now open up from revisiting it 20:46 #info snapd SRU exception request discussion has opened up policy questions that require further discussion 20:46 mwhudson: that was just an example. I think the chance of snapd upstream choosing to make a behavioural change in a stable release that some subset of Ubuntu users don't like is most certainly non-zero. 20:46 rbasak: indeed 20:46 i mean "existing" is already disliked by some subset of ubuntu users but well i'm being silly now 20:47 any objection to discussion with the SRU team to hear what they think? 20:47 I'll update the SRU team with the conversation 20:47 perfect 20:47 just want to get their opinions too though in addition to filling them in on our discussion :0 20:48 #topic Discuss again if we need to find a new member/have an election 20:48 #link https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2025/ubuntu-meeting.2025-03-11-20.00.log.html#l-261 20:48 What do we hope to gain by adding a new member mid-term? 20:48 This is always it seems on the agenda, but I think it's about time we look at and revisit this anyways. Back then, we decided we did not need a new member or need a new election for a TB slot. 20:48 I don't think we gain anything adding a new member 20:48 nor lose anything by not having a 5th member at the moment. 20:48 thoughts? 20:48 oops just saw rbasak ask a similar question, i got tunnelvisioned on writing mine xD 20:49 IIRC, we haven't had any contentious votes so far in this term. In general the TB usually achieves consensus. 20:49 part of the agreement when we decided this a year ago was to revisit in 6 months 20:49 i don't think we especially need a new member 20:49 I'm revisiting now :) 20:49 I don't think we need a new member either. 20:49 if we don't need one, then we can close the matter as "No new member is needed" 20:50 Another issue is that other action item for teward/CC to clarify the voting process, which presumably we'd need to add a new member. 20:50 i'm ok with that. seb128? 20:50 Sounds like a lot of work 20:50 rbasak: hence why i'm going to bring this up with the CC on that action item anyways 20:50 Together with the CC to run an election for one member, etc 20:51 And my other concern is that I'd like for there to be a set of good quality candidates and a meaningful vote. We're usually quite short of nominations, which is how we ended up here. 20:51 additionally I don't think we need to push for a one-member election, especially mid-term, and anything we've needed to decide has always been able to have quorum. 20:51 rbasak: indeed, I think that's going to become more and more of a problem as we continue on in time, as well, the vast majority of people just don't want to step up. 20:52 ideally I would like to have one extra member if we could find a good one with more time to allocate to the TB than most of us have... 20:53 in practice I'm not sure we will find someone matching that description 20:53 theory vs. practice. I don't think we will find someone matching that description before the end of our terms. 20:53 unfortunately. 20:53 this just being the current 'landscape' of users vs. who wants to contribute, etc. 20:53 and who wants to step up to *lead* 20:54 we're down to 6 minutes so I'll move my AOB to an email thread, heh. 20:54 time to allocate to the TB is an issue indeed 20:54 indeed, and i think that issue is present across teams too 20:54 But we've often deferred a topic because some TB members haven't done their homework yet. Surely adding TB members will make that worse? 20:55 or it could increase the chance of having a quorum of TB members who had the time to catch up on a topic 20:56 assuming again that we get a new member which is less overworked than us, which I doubt is likely to happen... 20:57 do we want to mull this over for one more time period and revisit next meeting for a final decision on this? (down to 3 minutes left on time slot) 20:57 (and I have a 4PM hardstop) 20:57 i think that sounds fine, yes (vote next time) 20:57 OK 20:59 ok 21:05 Well, we're well over time now. I guess we're done? 21:06 I guess so, teward said he had an hardstop so he probably ran away already 21:06 #endmeeting 21:06 I guess he needs to be the one doing it? 21:06 anyway, thanks everyone! 21:06 o/ 21:10 i got bombed by boss calls 21:10 yes it's over :P 21:10 #endmeeting