20:08 <teward> #startmeeting Ubuntu Technical Board
20:08 <meetingology> Meeting started at 20:08:44 UTC.  The chair is teward.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
20:08 <seb128> hey, sorry for being late, as usually it's a busy time of the day
20:08 <meetingology> Available commands: action, commands, idea, info, link, nick
20:09 <teward> seb128: no worries
20:09 <teward> today's the date and time set for the first 2026 meeting of the Technical Board
20:09 <teward> #topic Action Review
20:09 <teward> - 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 <teward> still carried over, CC has been a little slow on this but i'll rally them up again on this
20:09 <teward> #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 <teward> - 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 <teward> did we ever get data back from the team on this?
20:10 <rbasak> I just emailed the list about that.
20:10 <mwhudson> i see robie emailed about this just a few minutes ago
20:10 <rbasak> I've not heard anything.
20:10 <mwhudson> i'll talk to frank before the next TB meeting
20:10 <teward> ah then my email client is being slow.  at least we're on it and hunting it still
20:10 <teward> #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 <teward> right, onto the topics here on the agenda
20:11 <teward> #topic snapd SRU exception request
20:11 <teward> #link https://lists.ubuntu.com/archives/technical-board/2025-September/003050.html
20:11 <teward> #link https://code.launchpad.net/~ernestl/sru-docs/+git/sru-docs/+merge/493382
20:11 <mwhudson> i still haven't looked at this properly :(
20:11 <rbasak> I'd like to hear what the TB think about the re-exec behaviour.
20:14 <teward> 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 <teward> part of me wants to ask Security what they think about that behavior
20:14 <rbasak> It was added at some point without consultation with anyone on the Ubuntu side, AIUI
20:15 <mwhudson> 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 <seb128> I though that it was quite an old behaviour, do you know when it was added?
20:15 <rbasak> A long time ago, yes.
20:16 <mwhudson> 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 <rbasak> 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 <rbasak> It does seem like it makes the SRU process somewhat pointless in the case of snapd.
20:17 <mwhudson> it is certainly the case that the currently documented sru exception text is wildly out of date
20:17 <rbasak> Somewhat pointless to do both, anyway.
20:17 <rbasak> 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 <seb128> I would be in favor of that
20:18 <rbasak> But then it would seem odd to take snapd updates out of the hands of Ubuntu entirely.
20:18 <seb128> 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 <rbasak> Especially as snapd, AFAIK, is massively beyond the scope of Ubuntu snap packaging nowadays.
20:19 <teward> 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 <mwhudson> i'm not sure re-exec is really the part to focus on
20:19 <rbasak> teward: not much different from flatpak really there.
20:19 <teward> i'm not sure re-exec is the part to focus on here either.,
20:19 <rbasak> teward: or pip, for that matter
20:19 <mwhudson> question 1 is "do we want new snapd versions to be available to users of stable releases"
20:20 <mwhudson> i think the answer to this has to be yes, or there's not really any point to the whole project
20:20 <rbasak> I think the answer to that is "yes"
20:20 <mwhudson> question 2 is then, do we still want people with ubuntu hats to be involved in gating these updates?
20:20 <rbasak> 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 <rbasak> The principles from the third party repo reqs doc matter here I think
20:21 <rbasak> How do those principles apply to snapd itself?
20:23 <seb128> hum
20:24 <mwhudson> principles 3-8 are clearly fine for snapd
20:25 <mwhudson> 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 <rbasak> I can't find it in the docs. Link, please?
20:26 <rbasak> The TOC of the docs doesn't make sense to me any more :-(
20:26 <mwhudson> https://documentation.ubuntu.com/project/tech-board/3rd-party-software-sources/
20:26 <teward> i think it's this?  https://documentation.ubuntu.com/project/tech-board/3rd-party-software-sources/
20:26 <rbasak> Thanks
20:26 <teward> 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 <mwhudson> "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 <rbasak> So maybe we treat snapd as if it's entirely a snap
20:27 <rbasak> Given that it re-execs, it effectively is
20:27 <mwhudson> or upload a snapd with re-exec patched out, or whatever
20:27 <rbasak> And if principle 2 is maintained by the behaviour you describe, then fine
20:28 <rbasak> If that's where this takes us, then maybe that'd be easier for everyone?
20:29 <mwhudson> yes i think so
20:29 <mwhudson> 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 <rbasak> 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 <rbasak> upstream.
20:31 <teward> I think i still have one small confusion...
20:31 <teward> 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 <rbasak> 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 <rbasak> teward: they do update the .deb still, but the .deb re-execs to the snap subject to some criteria (version based IIUC)
20:33 <mwhudson> 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 <mwhudson> (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 <mwhudson> rbasak: +1
20:34 <teward> wouldn't the determinatino of whether to SRU each deb fall on the SRU and Release teams, not TB?
20:34 <teward> just, you know, thinking out loud
20:34 <mwhudson> 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 <rbasak> The SRU team would review each proposed snapd deb SRU, yes.
20:35 <rbasak> 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 <rbasak> Oh, one open thing is the scope of snapd
20:36 <rbasak> I get the impression it does more than just snap packaging nowadays.
20:37 <rbasak> 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 <rbasak> 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 <mwhudson> well it does have that stuff for TPM-FDE installs, but not for classic
20:40 <rbasak> This reminds me of Google's Play Services somewhat
20:40 <rbasak> If more functionality gets moved into there with the above proposal, then where are we with managing how Ubuntu works at all?
20:40 <mwhudson> it is not completely different for sure
20:41 <mwhudson> maybe we should discuss this aspect more next time.
20:42 <rbasak> For stable releases, perhaps the implied exception to principle 1 should apply to managing user-installed snaps only.
20:42 <rbasak> But even with that, I'm not sure about how this works with future changes and scope creep
20:43 <mwhudson> 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 <teward> 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 <teward> and we have only about 17 minutes left and one other agenda item
20:44 <mwhudson> yes
20:44 <teward> (though the other item might not be as time important)
20:44 <rbasak> Yeah I think we need further discussion another time
20:44 <rbasak> 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 <seb128> right, we aren't going to resolve those questions today/in the remaining minutes
20:44 <teward> #info snapd SRU exception request needs further discussion, remains as an active agenda item for discussion
20:45 <mwhudson> 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 <teward> 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 <teward> #info snapd SRU exception request discussion has opened up policy questions that require further discussion
20:46 <rbasak> 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 <mwhudson> rbasak: indeed
20:46 <mwhudson> i mean "existing" is already disliked by some subset of ubuntu users but well i'm being silly now
20:47 <teward> any objection to discussion with the SRU team to hear what they think?
20:47 <rbasak> <rbasak> I'll update the SRU team with the conversation
20:47 <teward> perfect
20:47 <teward> just want to get their opinions too though in addition to filling them in on our discussion :0
20:48 <teward> #topic Discuss again if we need to find a new member/have an election
20:48 <teward> #link https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2025/ubuntu-meeting.2025-03-11-20.00.log.html#l-261
20:48 <rbasak> What do we hope to gain by adding a new member mid-term?
20:48 <teward> 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 <teward> I don't think we gain anything adding a new member
20:48 <teward> nor lose anything by not having a 5th member at the moment.
20:48 <teward> thoughts?
20:48 <teward> oops just saw rbasak ask a similar question, i got tunnelvisioned on writing mine xD
20:49 <rbasak> IIRC, we haven't had any contentious votes so far in this term. In general the TB usually achieves consensus.
20:49 <mwhudson> part of the agreement when we decided this a year ago was to revisit in 6 months
20:49 <mwhudson> i don't think we especially need a new member
20:49 <rbasak> I'm revisiting now :)
20:49 <teward> I don't think we need a new member either.
20:49 <teward> if we don't need one, then we can close the matter as "No new member is needed"
20:50 <rbasak> 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 <mwhudson> i'm ok with that. seb128?
20:50 <rbasak> Sounds like a lot of work
20:50 <teward> rbasak: hence why i'm going to bring this up with the CC on that action item anyways
20:50 <rbasak> Together with the CC to run an election for one member, etc
20:51 <rbasak> 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 <teward> 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 <teward> 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 <seb128> 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 <seb128> in practice I'm not sure we will find someone matching that description
20:53 <teward> theory vs. practice.  I don't think we will find someone matching that description before the end of our terms.
20:53 <teward> unfortunately.
20:53 <teward> this just being the current 'landscape' of users vs. who wants to contribute, etc.
20:53 <teward> and who wants to step up to *lead*
20:54 <teward> we're down to 6 minutes so I'll move my AOB to an email thread, heh.
20:54 <rbasak> time to allocate to  the TB is an issue indeed
20:54 <teward> indeed, and i think that issue is present across teams too
20:54 <rbasak> 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 <seb128> 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 <seb128> assuming again that we get a new member which is less overworked than us, which I doubt is likely to happen...
20:57 <teward> 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 <teward> (and I have a 4PM hardstop)
20:57 <mwhudson> i think that sounds fine, yes (vote next time)
20:57 <rbasak> OK
20:59 <seb128> ok
21:05 <rbasak> Well, we're well over time now. I guess we're done?
21:06 <seb128> I guess so, teward said he had an hardstop so he probably ran away already
21:06 <seb128> #endmeeting
21:06 <seb128> I guess he needs to be the one doing it?
21:06 <seb128> anyway, thanks everyone!
21:06 <rbasak> o/
21:10 <teward> i got bombed by boss calls
21:10 <teward> yes it's over :P
21:10 <teward> #endmeeting