== Meeting information == * #ubuntu-meeting: Technical Board meeting, started by seb128, 24 Feb at 20:04 — 21:05 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2026/ubuntu-meeting.2026-02-24-20.04.log.html == Meeting summary == === Action Items === Discussion started by seb128 at 20:05. * '''rbasak to follow up on snapd SRU exception request discussion w/ SRU team''' (seb128, 20:07) * ''ACTION:'' seb128 to organize meetings about the snapd SRU exception (seb128, 20:13) * '''teward to reach out to Canonical Community Team to prod IS on issues with lists.u.c needing 'munge from' set for DMARC compliance on ALL mailing lists''' (seb128, 20:13) * ''ACTION:'' teward to change TB's list "munge from" setting (seb128, 20:20) * '''teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over)''' (seb128, 20:20) * ''ACTION:'' teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over) (seb128, 20:21) * '''(all members) Provide feedback in "RFC: SRU Exception for transitional hardware enablements (tHWE)" thread now that data is available''' (seb128, 20:21) * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2026-February/003094.html (teward, 20:22) * ''LINK:'' https://ubuntu.com/download/nvidia-jetson (rbasak, 20:36) * ''LINK:'' https://ubuntu.com/download/qualcomm-iot (rbasak, 20:36) * ''ACTION:'' rbasak to follow up on the list with the TB decision on the current "SRU Exception for transitional hardware enablements" (seb128, 20:58) === Scan the mailing list archive for anything we missed (standing item) === Discussion started by seb128 at 20:59. * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2026-February/003093.html (seb128, 21:00) === Check up on community bugs and techboard bugs (standing item) === Discussion started by seb128 at 21:03. === Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) === Discussion started by seb128 at 21:03. === AOB === Discussion started by seb128 at 21:05. == Action items, by person == * rbasak * rbasak to follow up on the list with the TB decision on the current "SRU Exception for transitional hardware enablements" * seb128 * seb128 to organize meetings about the snapd SRU exception * teward * teward to change TB's list "munge from" setting * teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over) == People present (lines said) == * rbasak (78) * seb128 (60) * teward (45) * mwhudson (24) * meetingology (6) == Full log == 20:04 #startmeeting Technical Board 20:04 Meeting started at 20:04:45 UTC. The chair is seb128. Information about MeetBot at https://wiki.ubuntu.com/meetingology 20:04 Available commands: action, commands, idea, info, link, nick 20:05 #topic Action Items 20:07 #subtopic rbasak to follow up on snapd SRU exception request discussion w/ SRU team 20:07 I did discuss this with the SRU team. 20:07 (sorry was looking for the previous meeting log as reference) 20:07 I think everyone was generally OK with the direction of our previous discussion here. 20:08 To make progress maybe we need a realtime discussion with the SRU team and try to reach a decision together. 20:08 I suggested that, but maybe it's better for a Canonical person to arrange a time since most people involved are Canonical. 20:08 (and you can easily see calendars, time zones, etc). 20:08 I can organize a meeting 20:08 Thanks! 20:08 who should be there? everyone who want to join from SRU team + TB? 20:09 i suspect my presence will make scheduling difficult but i am happy to not be there if it helps 20:09 I think that the general consensus is going to be something around accepting the re-exec behaviour, perhaps with conditions and expectation setting on upstream as mitigation, and then massively relaxing the level of review the SRU team perform. 20:10 All SRU and TB should be invited IMHO, and maybe people from the snapd side? Ernest? Anyone else he nominates? 20:10 yeah letting ernest nominate people makes sense 20:10 alright 20:10 Like this meeting is public, I think that meeting can be public, but better on Google Meet to get it done 20:10 ack 20:10 (like maybe zyga would be good? not sure) 20:11 Andreas is in the above set but strictly needed I think. 20:11 rbasak, do you have a public calendar/list of days|times that would work for you? 20:11 I'm sorry that's difficult for me to provide, but I can give you a set of times privately or something. 20:12 (I assume this will be during the UK working day, so I have to consider my work calendar) 20:12 yeah, just a general "those range of times are usually fine during the week" or something 20:12 OK. I'll ping you privately 20:12 let's talk details in private, no need to hold the meeting for that 20:12 thanks 20:12 i'll have to math my availability with regards to timezones, but i can get you my availability if you *need* me on the call. again poke privately. : 20:12 : 20:12 :) * 20:13 *throws keyboard out window* 20:13 seb128: maybe tomorrow daytime is best, when I have the work calendar open? 20:13 #action seb128 to organize meetings about the snapd SRU exception 20:13 * meetingology seb128 to organize meetings about the snapd SRU exception 20:13 rbasak, sounds good yes 20:13 Thanks 20:13 #subtopic teward to reach out to Canonical Community Team to prod IS on issues with lists.u.c needing 'munge from' set for DMARC compliance on ALL mailing lists 20:14 so 20:14 mixed response on this 20:14 let em open my matrix logs i had a chat with the CCT on this 20:14 teward: I think maybe given existing people involved together with timezones, we should make you and mwhudson optional? No decision would be made at the meeting I don't expect, but hopefully a proposal that you'll be fine with later. 20:14 rbasak: yeah, optional is fine, as long as someone gets me a bullet point summary and a proposal 20:14 ack 20:15 so the info I got back from Aaron Prisk is "when I spoke with IS folks last evening, they were letting [people internally] know about upcoming changes to DMARC policy and the plan looks to be to push them in the first few days of March." and "My understanding was [the forcing of 'munge from' on mailing lists] was on that list of comprehensive changes to be made" 20:16 that was on the 16th, they said they'd check and get back to me 20:16 so I am aware that at least based on Aaron's statement, the DMARC changes and such are on IS's radar 20:16 but there's no hard date set 20:16 in the interim, I suggest *we* simply change the policy for our lists we maintain. Case in point, Community Council accepted that change to their list, enabling Munge From DMARC mitigations 20:17 I wish they'd just turn on 'munge from' right now to mitigate :-( 20:17 rbasak: I have words about IS that I will save for when we're not emeting in an official capacity 20:17 This is effectively an outage that has gone on for months :-( 20:17 ones that Mauro and Aaron have both heard. 20:17 ack 20:17 rbasak: I can poke Aaron again, but at least for Tech Board lists, I'd like to raise a vote: enable "Munge From" mitigations for TB list 20:17 yes or no 20:17 i'm +1 for it 20:17 yes 20:17 +1 20:18 +1, but I think we were already +1 on the list a long time ago. 20:18 It just needs doing by those who have access. 20:18 indeed, last i checked it wasn't turned on 20:18 (I don't think I do) 20:18 i'll switch it on after lunch 20:18 (I have access) 20:19 just poked Aaron again for an update 20:19 and reiterated we consider this an "extended outage of mailing list functionality" 20:19 Thank you for chasing teward 20:19 thanks indeed 20:19 next. 20:20 #action teward to change TB's list "munge from" setting 20:20 * meetingology teward to change TB's list "munge from" setting 20:20 #subtopic teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over) 20:20 carry over 20:21 #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:21 * 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:21 #subtopic (all members) Provide feedback in "RFC: SRU Exception for transitional hardware enablements (tHWE)" thread now that data is available 20:21 Robie just sent an email to the list about that 20:22 (currently reading) 20:22 well rbasak is the only one to provide feedback so far and did it three minutes before the meeting 20:22 :) 20:22 I studied all the previous conversations in writing that. It took quite some time. But I think it's important that if I'm -1 then I provide specifics as to why. 20:22 #link https://lists.ubuntu.com/archives/technical-board/2026-February/003094.html 20:22 Sorry. It took a long time to produce that! 20:22 (ops get chair by default xD) 20:22 yeah well i haven't replied at all so i can't complain! 20:23 i haven't replied either, but rbasak you basically made all my points clear. 20:23 met and exceeded what I would bring up 20:26 I should add that if you wish to vote +1 then I think you need to define exactly what you are approving, since that's a can of worms in itself. I explained why towards the end of my email. 20:26 One thing I forgot to mention there is that a +1 means that we would need to also define some guidance for the SRU team so that they know exactly how to determine whether an upload falls within whatever exception you want to define. 20:27 I'm -1 on the topic as well, because **fundamentally** what is being asked is to lower quality standards and break existing 'release support' traditions and expectations. 20:27 as rbasak stated. 20:27 he just said it more eloquently :p 20:28 I think it's a bit more nuanced than that 20:28 I'm not aware of any nuance that I haven't already rebutted in my latest email. No nuance that has already been mentioned, anyway. 20:28 in practice video driver, kernel, etc might already break support for some hardware, it doesn't block us from updating the kernel 20:29 (rebutted, or acknowledged, since I accept that some points are valid but just don't weigh enough) 20:29 seb128: what do you mean? AIUI, kernel updates in a stablee release that regress support from some hardware are banned (by policy, anyway; bugs happen of course). 20:30 I was speaking about "if your hardware work on a release of Ubuntu you can expect it will work on the current series" 20:30 that's a reasonable assumption but already not always true in practice 20:31 Oh, I see. I addressed that already in the paragraph beginning "I accept that features do eventually get dropped". 20:32 i would like an extra 8 hours a day to get my thoughts organized on this (and other topics) :( 20:32 would it make a difference to your argument of new install if the installer was able to tell users upfront "that config isn't supported by this version of Ubuntu"? 20:33 That would be better. I'm not sure that's always possible. But I don't think it's enough mitigation to change my opinion. Because it'd be too late for the user - they'd already have formed an expectation by that stage that would be broken. 20:34 I agree that it would be nice if any enabled configuration was working from that point on with any version of Ubuntu, but we are talking about cases where companies doing the enablement aren't wanting to commit to that, and the policy isn't going to change the fact 20:34 so our choice is to have those config working on no version of Ubuntu out of the box, or on some 20:34 I think that's fine, and we can still serve those companies by using a PPA or by resurrecting the partner archive. 20:35 but then standard Ubuntu isn't going to work out of the box 20:35 For most of the hardware mentioned, a custom image is required anyway. If that includes the PPA or partner archive, then it *does* still work out of the box. 20:35 if I'm buying one of those machines and try to install Ubuntu it will just fail unless I know how/where to find the image enabling the ppa needed 20:36 Isn't that the case anyway? 20:36 https://ubuntu.com/download/nvidia-jetson 20:36 Custom image 20:36 https://ubuntu.com/download/qualcomm-iot 20:36 Custom image 20:36 And so on. 20:36 i think there are kind of many cases here and it's not necessarily the case that the answer has to be the same for all of them (although the reasoning is certainly easier if it is) 20:37 Going by Frank's email, these images are the main driver for the request, so I think it's reasonable to consider them first. And these arguments don't apply to these. 20:37 like there is the OEM case where a laptop doesn't quite work right with the generic kernel. sometimes it is enough to run the default installer, which can then install a special kernel to give the user a good experience. but sometimes the default installer doesn't even boot 20:38 (i think the DGX spark is like this) 20:38 but ask robie says, most of the issues are for devices that we have per-device images enabled anyway 20:39 er -enabled 20:39 If you _can_ implement this using the default installer, then there's another way out. Give the user adequate notice that a PPA is required and release upgrades won't work, then do it. 20:40 well, one point to consider in Frank's email is also the upgrade case. If we have the support in the archive with safe-guards in the upgrader/installer we can warn users/block upgrades to newer version 20:40 Either way, it doesn't really hurt the UX except for the notice (which I argue is better than a future release upgrade disappointment) 20:40 that's more difficult to do if the supports come from a ppa 20:40 they would need to have a patched dist-upgrader and rebase on SRUs 20:41 I also addressed some of that in my email. Not all users use the release upgrader to get a new release. They reinstall instead. In professional environments I'd say it's <50%. 20:41 or we would need to start doing archive tweaks to the upgrade to handle ppas situations 20:41 (maybe more on desktop though admittedly) 20:42 release-upgrader already has PPA disabling support. 20:42 to be extremely contrary, you could argue about how having images labelled ubuntu that enable a partner archive/ppa and have all the downsides above is different from allowing this behaviour in the archive 20:42 I'd be OK with it being enhanced, including in SRUs, to do something appropriate UX-wise if "blessed PPAs" and/or partner archive is detected. 20:42 right, but the issue is not disabling, it's being able to predict if the hardware is working with what is in the newer series 20:43 mwhudson: well, you're right, and IMHO we _shouldn't_ certify Ubuntu unless the enablement is done properly, including release upgrades. But that's perhaps not within our remit to decide. 20:43 (and including in the main archive) 20:44 seb128: OK, but I don't think that's insurmountable or even really that tricky. It is slightly more work I accept. 20:44 of course this runs straight into the "ubuntu as community prohect" vs "ubuntu certification being something a commercial company sells" issue which is of course lurking behind all of this 20:45 A middle ground is that I'd be OK with Ubuntu certification relying on partner. 20:45 And then leaving it to Canonical to define what that means. 20:45 "Ubuntu Partner Certified" maybe. But I don't get to define marketing/trademark use. 20:46 we kind of already do this with the oem archive but of course i don't know that the techboard ever approved of that approach! (i don't think it did) 20:47 Anyway, I don't think the community so much care about the branding. For a community perspective, keeping the main archive clean, and overlays well marked for users who wish to avoid them is probably sufficient. 20:48 AIUI, the OEM archive is (was?) operated with a "can't go in unless upstreamed" philosophy. 20:48 I am running on OEM hardware right now and I never had trouble release upgrading. 20:48 For me, it worked - the development release apparently _was_ fixed first. 20:48 If that's not how the OEM archive is operated any more, then IMHO that's a problem. 20:48 heh for me it was not but it was all expected devel series disruption really 20:48 But it's not the problem we're faced with right now, and we can't boil the ocean. 20:50 Anyway, here we are. 20:50 I think I had already considered all points raised so far. 20:50 so i feel like the current sentiment is something like: -1 on the proposal as posted. maybe seb and i can work with PE on a process involving some kind of non-main archive to enable these cases. 20:51 That works for e. 20:51 me 20:51 no solution is perfect and I've no strong preference either way, I see value in each approach 20:51 yeah i'm -1 as proposed, if there were better ways (i.e. partner or OEM repos/PPAs as overlayed or such) then I could probably get behind it, but as written I'm -1 on the proposal. 20:52 I would be fine settling for a -1 for now and having another round of discussion with PE on how to solve their issues another way 20:52 i also wonder if there is a sub-issue about what to do about packages already in the archive 20:52 Can we call that agreed then, so we can write back to the thread and at least close this chapter? To be clear, I still think there's a path forward, but I also don't want observers to consider the matter stalled. 20:52 I asked about packages already in the archive and how they were held up, but didn't get a clear example broken UX, apart from the inability of users to release upgrade (ironic I think!) 20:53 I'd be happy to consider those case-by-case if/when they are raised to us. 20:53 if we go into the current voting analysis: rbasak is -1 still from email, I'm -1, mwhudson is -1 on the proposal as posted, and seb128 can be 0 (abstain because no strong preference) leaving us with a -3 consensus. If we analyze this at least at that point. 20:54 However, I think additional sub-issues should be handled as independent issues 20:54 and going back to PE and discussiong and such isn't necessarily a bad thing 20:54 but we *do* need to show that we've discussed and IMO decide on **the proposal as written** 20:54 since it's been sitting for A Long Time(TM) 20:56 right 20:57 how to solve their issues another way> Am I missing something here? Using a different archive solves this immediately, does it not? I haven't heard anything on why this can't be done, except for optics (AFAICT). 20:57 rbasak, do you want an action to follow up with the outcome of that discussion? 20:57 Sure, thanks. 20:57 thanks 20:57 By all means we can help PE with the technicalities of setting up that archive. 20:57 But I don't think that'd be blocked on the TB or any other goverance in any way, would it? 20:58 I don't disagree with rbasak, there's alternatives like using partner archives or a new OEMPartner archive or whatever, or custom images with PPAs overlaid. But I don't think the TB decision on the proposal as is *blocks* those options 20:58 it just blocks the "we want this in the main repositories and exceptions abound" for it as was proposed. 20:58 yeah it's more something for me to work in my day job rather than TB hat 20:58 #action rbasak to follow up on the list with the TB decision on the current "SRU Exception for transitional hardware enablements" 20:58 * meetingology rbasak to follow up on the list with the TB decision on the current "SRU Exception for transitional hardware enablements" 20:58 OK, thanks! 20:59 #topic Scan the mailing list archive for anything we missed (standing item) 20:59 there is the LTS qualification for kubuntu 20:59 which i thought we had already approved but apparently not! somehow we forgot about kubuntu entirely when discussing this before 21:00 https://lists.ubuntu.com/archives/technical-board/2026-February/003093.html 21:00 FYI regarding technical-board list, Munge From for DMARC Moderation Action (and mitigation) is now enabled 21:00 i just did that since i was temporarily IRC-kicked 21:00 thx 21:01 oh also we are at time. i guess we ask the release team for their input here? (but given kubuntu's long history i don't see us saying no, somehow) 21:01 RE: Kubuntu, didn't we decide this should probably be better handled by the Release Team than the TB? I could have sworn we offloaded this, or intended to offload this, to the Release team 21:01 we're also out of time 21:01 right, I was going to say 21:01 RT to decide and do their recommendation 21:02 Yes - we agreed with the release team that they would make recommendations to us in the first instance. 21:02 I asked if we should redirect these emails to them, and they said they'd be happy to just monitor the list. 21:02 So they should already know, and we can await a recommendation from them. 21:02 (maybe ping them though :) 21:03 I will ping them 21:03 ok, let's kickly move on 21:03 #topic Check up on community bugs and techboard bugs (standing item) 21:03 nothing new there 21:03 #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) 21:04 if we go in order next chair would be teward with mwhudson as backup 21:04 fine with me (also fine to chair next time i think) 21:05 #note teward will chair next TB meeting, mwhudson is backup. 21:05 #topic AOB 21:05 anything else quick? 21:05 (nothing from me) 21:05 nothing from me 21:05 Nothing from me 21:05 it's a wrap then, thanks everyone! 21:05 Thank you for chairing! 21:05 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)