== Meeting information == * #ubuntu-meeting: Ubuntu Technical Board - 2025-11-18 meeting, started by teward, 18 Nov at 20:05 — 21:05 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2025/ubuntu-meeting.2025-11-18-20.05.log.html == Meeting summary == === Action review === Discussion started by teward at 20:05. * '''rbasak to reply to Mauro after 48 hours unless mwhudson objects''' (teward, 20:05) * '''rbasak to reply to mail about unity flavour on mailing list''' (teward, 20:06) * '''teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over)''' (teward, 20:06) * ''ACTION:'' teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over) (teward, 20:07) * '''seb, thomas, michael to provide feedback in "RFC: SRU Exception for transitional hardware enablements (tHWE)" thread''' (teward, 20:07) * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2025-September/003051.html (teward, 20:11) * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2025-October/003055.html (teward, 20:11) * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2025-November/003073.html (teward, 20:11) * ''LINK:'' https://docs.google.com/document/d/1libyBHG7hV9PmIi-5M-jJZV8KxfxLlX6HR7iLTatCvE/edit?tab=t.0#heading=h.vuwb4i3hth1q (teward, 20:30) * ''LINK:'' https://docs.google.com/document/d/1yLb1sUa6gXTT8BKe5vBDmK5AtQKfDA75G4MEpdi1Ir0/edit?tab=t.0#heading=h.sgumsf200jh5 (teward, 20:36) * Requires further discussion and a potential future agenda item for further discussion (teward, 20:41) === Scan the mailing list archive for anything we missed (standing item) === Discussion started by teward at 20:43. === Check up on community bugs and techboard bugs (standing item) === Discussion started by teward at 20:45. * ''ACTION:'' rbasak to follow up with release team on delegating LTS requalification to them. https://lists.ubuntu.com/archives/ubuntu-release/2025-July/006430.html (teward, 20:46) === Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) === Discussion started by teward at 20:46. * rbasak is next chair, with seb128 as backup (unless otherwise noted in agenda page) (teward, 20:47) === AOB === Discussion started by teward at 20:48. * '''LTS requalification requests and processes''' (teward, 20:48) * Awaiting more info from release team on how they'd like this process to work (teward, 20:52) * ''LINK:'' https://wiki.ubuntu.com/RecognizedFlavors and related pages? (mwhudson, 20:52) * '''(mwhudson) what can go into multiverse https://github.com/ubuntu/ubuntu-project-docs/pull/309''' (teward, 20:55) * Further discussion required (teward, 21:04) === Next meeting date, time === Discussion started by teward at 21:04. == Action items, by person == * rbasak * rbasak to follow up with release team on delegating LTS requalification to them. https://lists.ubuntu.com/archives/ubuntu-release/2025-July/006430.html * teward * 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) == * teward (106) * rbasak (64) * fheimes (26) * mwhudson (25) * seb128 (11) * meetingology (4) * ilvipero (3) == Full log == 20:05 #startmeeting Ubuntu Technical Board - 2025-11-18 20:05 Meeting started at 20:05:10 UTC. The chair is teward. Information about MeetBot at https://wiki.ubuntu.com/meetingology 20:05 Available commands: action, commands, idea, info, link, nick 20:05 Hello hello! 20:05 #topic Action review 20:05 Gonna do these slightly out of order 20:05 #subtopic rbasak to reply to Mauro after 48 hours unless mwhudson objects 20:05 Done 20:06 this was done i think 20:06 yay! 20:06 #subtopic rbasak to reply to mail about unity flavour on mailing list 20:06 I think that was done as well 20:06 nice, getting all the actino items out of the way 20:06 #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:06 I'm still keeping this on because the TB still hasn't made a decision (we've had bigger fish to fry lately) 20:06 s/TB/CC/ 20:07 #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:07 * 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:07 #subtopic seb, thomas, michael to provide feedback in "RFC: SRU Exception for transitional hardware enablements (tHWE)" thread 20:07 i haven't done this yet :( i have done some thinking but not yet put the thoughts into an email 20:08 Frank replied to the ML today 20:08 same, I did share a few though on the chat on the day of the previous meeting we didn't have 20:09 I don't think Frank has addressed any of my concerns. I can go into detail if it appears otherwise to you. 20:09 frank is here if we want to talk about it live 20:09 i must have missed that message if it was recent., 20:09 but yeah i saw fheimes here 20:09 I also don't follow what sort of exception is being requested here. 20:10 yes - I'm here 20:10 Surely it isn't just that if policy can't be met then we can ignore it? 20:10 So what is exceptional about this case that warrants an exception? 20:10 fheimes: hi! Feel free to speak :) 20:11 Also, why can't this be done in partner.canonical.com or in the OEM archive? 20:11 the exception is described in the proposed approach in the tHWE gDoc: https://docs.google.com/document/d/1libyBHG7hV9PmIi-5M-jJZV8KxfxLlX6HR7iLTatCvE/edit?tab=t.0#heading=h.vuwb4i3hth1q 20:11 "We propose an exception that the requirement that the (optimized) platforms need to be enabled in newer versions first is not needed, provided that appropriate measures are taken to prevent release upgrades on affected platforms - in particular, a “quirk” for the ubuntu-release-upgrader. This ensures that users are not able to upgrade to a newer version of Ubuntu where their hardware is not supported." 20:11 partner.canonical.com does not exist in any meaningful way any more 20:11 mwhudson: so bring it back 20:11 #link https://lists.ubuntu.com/archives/technical-board/2025-September/003051.html 20:11 #link https://lists.ubuntu.com/archives/technical-board/2025-October/003055.html 20:11 Or use a PPA 20:11 #link https://lists.ubuntu.com/archives/technical-board/2025-November/003073.html 20:11 (adding for ML link reference in agenda) 20:12 partner.c.c is no longer 20:12 I believe PPAs are already being used for other "certified" hardware 20:12 the packages we talk about are asked to be in the archive 20:12 "However we believe that the transitional hardware enablements benefit from the scrutiny and transparency of being in the main archive, it does allow the Ubuntu teams to weigh in on these enablements and ensure they otherwise live up to the usual Ubuntu standards" 20:13 Well, I disagree with that. You're only here because you *don't* want to live up to the usual Ubuntu standards. 20:13 PPAs come with some drawbacks, usability, visibility, and security maintenance 20:13 Are we going to have this conversation again for any other quality standard you don't want to meet? You can't then use that to argue that you're here because you want to *uphold* said standards :) 20:13 fheimes: I disagree with basically all of that. 20:14 fheimes: usability is moot if users are downloading an image and then never doing a release upgrade as you claim. 20:14 Visibility is also moot for the same reason 20:14 Security maintainance is important, but it can be done in a PPA and I'm aware that the security team already have processes to security-maintain "blessed" PPAs 20:14 So it can all be done, and is already being done in other cases. 20:16 @rbasak: I don't say that things cannot be done in this way; but packages are already in the archive and need updates and maintenance, and that is where people are stuck 20:16 also fheimes i want to put a huge caution flag on one thing you said: 20:16 > I would also expect that users follow common sense 20:17 **rule #1 of IT: assume the users are not going to follow common sense** 20:17 (rule #0 is "ALWAYS BACK UP YOUR DATA") 20:18 so i just want to put a caution in there that if you're expecting users to use common sense, they usually don't *have* it (you can see this for yourself on any of the support mediums where Ubuntu support is provided with people just blindly doing things that ChatGPT or random internet guides tell them without reading) 20:18 fheimes: AFAIK, you're asking to add *new* packages into the archive, are you not? 20:18 i think the packages are already there, in some cases 20:18 Which ones? Do we have a list of what is there and what is not? 20:18 please notice that the user set is different, these users are more commercial users 20:19 The SRU I rejected was for a new hardware enablement, not an existing one, AIUI. 20:19 fheimes: i'll save you my tirade about "the latest generation of corporation and commercial sysadmins" then. (point still stands) 20:19 fheimes: I don't think you can make that claim. The moment it goes into the Ubuntu archive, hobby users expect stuff to work, too. 20:19 ^^ that 20:20 @rbasak: there are multiple cases in flight - one could well be an existing package that should have received an hwe SRU 20:20 And it's today's hobbyists who become tomorrow's professional users. Their expectations of quality are forming today, and past quality is why Ubuntu has commercial success today. 20:21 well, it works on the certified ubuntu release (that is why certifications are done, no?) 20:22 quality is exactly what people look at when they perform a certification of a certain board on a specific Ubuntu release 20:22 fheimes: maybe some clarity here would help. You're using existing packages and functionality as a justification here, so could you (probably not right now) detail specifics of what packages and functionality you're relying on to make that claim? 20:22 that is to say, a real-world example where this would be needed and where this claim is based on 20:22 rather than the generic 'hypotheticals' not clearly defined in your claims 20:22 (to build off rbasak's request) 20:23 it is definitely the case that there are systems today where if you stick in an interim release ISO you will not have a good time (some OEM certified laptops). these use a separate archive though and it's not completely clear that the approach they use was ever oked by the TB 20:23 My understanding was that the OEM archive always had the condition of entry that enablements were first performed on the development release exactly for this reason. 20:24 Did that change? 20:24 I think the tHWE gDoc references a more detailed doc that mentions and discusses several real world examples 20:24 fheimes: i will caution that you link in that document to a 'tl;dr' document that nobody has access to 20:24 I don't have access to that. 20:24 i don't know but i'm fairly sure that releases between the LTS and devel do not get enabled 20:24 fheimes: so you actually *haven't* given us that information we need to properly view those cases, etc. 20:25 rbasak: yes you do, the doc is public 20:25 oh wait, which doc is it 20:25 > Further details, tl’dr: Special package / archive cases in PE 20:25 ^^ this doc E:NOACCESS 20:25 Nope 20:25 Not working for me. 20:25 *that* gives the details on the special cases, etc you're referring to 20:25 **that** is not a public document 20:25 tHWE proposal without details is, but not the linked document in that 20:26 > My understanding was that the OEM archive always had the condition of entry that enablements were first performed on the development release exactly for this reason. 20:26 I don't think that was the case 20:26 I assume people had access in the past, but no longer have (to the doc with the details) - I am happy to share based on a different mail address 20:26 of the reason OEM team had their archive was to be able to enable devices taking shortcuts when needed before the patches were ready to land in mainline 20:26 the tHWE gDoc is considered a summay 20:26 mwhudson: releases between the LTS and devel do not get enabled> OK, but that's a pretty short window. Here, we seem to be talking about the next *LTS* not being enabled until well after it is released. At least that's the SRU case I previously rejected. 20:26 fheimes: access control could be changed to "anyone who has the link can view" that document, but the 'summary' is not enough for us to act on IMO 20:26 we need details, actual cases for analysis, etc. 20:27 as it stands it's not fully clear, at least to me, what cases the proposal would cover / apply to 20:27 seb128: mainline meaning upstream or Ubuntu devel? 20:27 and as rbasak mentioned, we'd *like* such details to actually evaluate better the claimed scenarios 20:28 teward: it is already shared by anyone with the link 20:28 fheimes: the **summary** is, you also link to a document called "Special package / archive cases in PE" and that 'embed' is not a link 20:29 it won't give us access because the raw share link isn't embedded. 20:29 rbasak, Ubuntu devel & upstream 20:29 fheimes: (I requested access *to* the document for this case thougH) 20:29 sometime things are just not ready/quality enough to be in the main archive 20:30 #link https://docs.google.com/document/d/1libyBHG7hV9PmIi-5M-jJZV8KxfxLlX6HR7iLTatCvE/edit?tab=t.0#heading=h.vuwb4i3hth1q 20:30 please note that we shouldn't have been in this situation in the first place and look for a solution afterwards 20:30 but since we are there, we need to find a way to get unblocked 20:30 mid and long term all packages with all patches needed should be in all Ubuntu releases - that approach didin't change 20:31 seb128: my understanding is that there was never a hard requirement to upstream anything before landing in Ubuntu (that applies to all of Ubuntu development really), but for the OEM archive, it _was_ required to enable Ubuntu devel first. But I'm not sure this was ever endorsed by the TB, as it's not the main archive, but we're talking about the main archive here, so it's not really within scope of 20:31 any justificatoin today. 20:32 fheimes: can you make the specifics public, please? 20:32 fheimes: my interpretation of this request, and until I get other evidence to the contrary is likely not going to change, is that "Because a given newer Ubuntu release is not yet supported by our architecture / OEM systems / etc. and we don't have a reasonable timeline for that support, we want to explicitly enable hardware enablement on an older system and at a later date circle back to enable things in a later release." 20:32 where "later release" is either an existing stable release after a given release but not before the development release 20:32 fheimes: if you wish to rely on the argument that there are packages and functionality already in the archive, then I think the specifics of that need to be presented really. 20:32 it is public already 20:32 fheimes: **no it is not** 20:33 if you aren't going to give us a direct share link for this 20:33 then it's not public 20:33 because that's not how gDocs work 20:33 fheimes: "Special package / archive cases in PE" is not public 20:33 ^^ this 20:33 I have yet to see a list of packages and functionality you're using to justify your position. 20:33 fheimes: if you are not able to give us access to that document with a link you can share here to us, then it's not a public document 20:34 Maybe we need to move on? 20:34 yes i'm not sure there's much value in more real time discussion 20:34 I was going to sugges that, fheimes needs to get all the document public/shared and then we should probably postpone until next time (or follow on the list) once people have read those 20:35 it is public to anyone that has the link - this is the link: https://docs.google.com/document/d/1yLb1sUa6gXTT8BKe5vBDmK5AtQKfDA75G4MEpdi1Ir0/edit?tab=t.0#heading=h.sgumsf200jh5 20:35 oh. that is not the link in the summary document 20:35 fheimes: that link is not in the summary document as a link 20:35 (somehow) 20:35 I can confirm that this link works in a private browser instance 20:35 the other document is *emedded* as an Google Documents integration/link 20:35 not a public share link 20:36 #link https://docs.google.com/document/d/1yLb1sUa6gXTT8BKe5vBDmK5AtQKfDA75G4MEpdi1Ir0/edit?tab=t.0#heading=h.sgumsf200jh5 20:36 that is the summary dog: https://docs.google.com/document/d/1libyBHG7hV9PmIi-5M-jJZV8KxfxLlX6HR7iLTatCvE 20:36 s/dog/doc 20:37 (and I see people having it open ...) 20:38 That works, thanks. 20:38 anyway, it is probably to long to read it now - on the fly (that was the reason for the sum. doc) 20:39 I see some packages listed there, but I still have the question: what specific use cases are broken, eg. images that you've shipped that don't work, and require an SRU, that are blocked? 20:39 AFAICT, you're asking for new hardware enablements in these SRUs only. 20:39 And I'm not aware that bug fixes for existing functionality is being blocked in SRUs at all. 20:40 I would need to go through the squads that work on the different platforms to filter for that 20:41 OK 20:41 So let's postpone further discussion I guess 20:41 but it's both fixes/maintenance and hwe 20:41 #info Requires further discussion and a potential future agenda item for further discussion 20:42 i'll table this for now so we can have further discussion and information provided 20:42 i suggest we (TB) reply on the thread indicating what additional information we require to further gauge this outside of meeting time/space 20:42 (or plan specific meeting times for this discussino) 20:43 #topic Scan the mailing list archive for anything we missed (standing item) 20:44 going back the past couple months I see LTS requalification submissions are still coming into the TB 20:44 i sawa reply to Robie's email on the Unity thing but i don't see it necessarily asking for *TB* input on followup questions necessarily in it 20:44 and save for Frank's reply on the tHWE thing, there's nothing else in the November archives I'm aware of 20:44 yeah i don't think that email warranted a reply iirc 20:44 yeah i glanced and didn't think it did 20:45 #topic Check up on community bugs and techboard bugs (standing item) 20:45 On the LTS requalification 20:45 I did ask here: https://lists.ubuntu.com/archives/ubuntu-release/2025-July/006430.html 20:45 I think some process and documentation changes are needed to get this going smoothly. 20:45 rbasak: i think we should prod the release team then 20:45 and get a reply 20:45 I'll reply to my reply 20:46 #action rbasak to follow up with release team on delegating LTS requalification to them. https://lists.ubuntu.com/archives/ubuntu-release/2025-July/006430.html 20:46 * meetingology rbasak to follow up with release team on delegating LTS requalification to them. https://lists.ubuntu.com/archives/ubuntu-release/2025-July/006430.html 20:46 #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) 20:46 rbasak is backup on this meeting today, and becasue i've been otherwise busy on other meetings i guess the loop has been broken, should I just start back with you rbasak? 20:46 (email sent) 20:46 Sure 20:46 how do we deal with flavor LTS qualifications request? not worth discussing here? 20:47 seb128: last talk on it was the request to the release team for info on how they would want to handle it, etc. and get documentation and processes written up 20:47 seb128: I think the answer is at https://lists.ubuntu.com/archives/ubuntu-release/2025-July/006429.html and this is just a process specifics question? 20:47 we also only have 13 minutes and mwhudson put something else on the agenda 20:47 my thing is not very important 20:47 #info rbasak is next chair, with seb128 as backup (unless otherwise noted in agenda page) 20:47 ah, right 20:47 well it might spin off some discussion but it's not _urgent_ 20:48 #topic AOB 20:48 now we can talk about LTS requalifications stuff :0 20:48 (just wanted to get to that topic XD) 20:48 #subtopic LTS requalification requests and processes 20:49 right now because no other process has been published anywhere, everyone's using the old ones 20:49 that requalifications go via us - TB 20:49 Right. 20:49 so I think we need to document process changes so it is delegated to Release Team and *documented* that the Release Team handles it 20:49 as soon as that is published and ACK'd by us then Release Team takes charge 20:50 in the interim, we could forward the incoming requalification requests to the Release Team members and let them triage them under the new but not published policies. 20:50 s/policies/processes/ 20:50 but at this point we are, I believe, waiting for the Release Team's coming back from the july email that Robie just repoked into their radar 20:51 so i think we'll just have to wait for a reply in this case? 20:52 I think so yes 20:52 yes 20:52 awesome 20:52 where is the existing process documented? is it still on the wiki? 20:52 #info Awaiting more info from release team on how they'd like this process to work 20:52 https://wiki.ubuntu.com/RecognizedFlavors and related pages? 20:53 There's also the upcoming flavour spec work 20:53 Which AIUI will replace the wiki docs 20:53 ah right yes that can of worms 20:53 ilvipero: ^ 20:54 with only five minutes left effectively, we may have to bring that up for future discussion 20:54 although the current spec doesn't talk about LTS qualification in detail from a very quick skim 20:55 so yeah i have a PR to try to be more explicit about what multiverse is https://github.com/ubuntu/ubuntu-project-docs/pull/309. as robie noticed this is at least in part from the ubuntu-policy source package 20:55 i think even though the spec doesn't mention it wherever we mention it we need the release team's input first on how they want the new delegation process to flow 20:55 #subtopic (mwhudson) what can go into multiverse https://github.com/ubuntu/ubuntu-project-docs/pull/309 20:56 i see Robie already replied on the PR mwhudson did you review and reply? 20:56 ... at least I think that's Robie 20:56 Yes 20:57 Thanks for the ping, yes I have planned time with Utkarsh to discuss this topic in the flavor spec. 20:57 i must say i am skeptical that we can regard an unrendered SGML document that has not seen a meaningful update since 2009 as normative policy but that's a separate discussion -- making the ubuntu policies part of the project docs or something is probably something that should happen at some point some how 20:57 Thanks ilvipero! I'd be nice to have the process in (or linked from) the flavour spec to implement https://lists.ubuntu.com/archives/ubuntu-release/2025-July/006429.html together with the documented requirements 20:58 mwhudson: sure, but it is the status quo until then IMHO. 20:59 RE: multiverse, i will point at https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/latest/explanation/archive/#components just as a note that it touches upon 'multiverse' - are we simply looking for expansion on this mwhudson? 20:59 (this IS the packaging guide after all) 20:59 (IOW, we can't and shouldn't consider the policy changed in any way, and if we want to actually change it, then changing that text is straightforward enough) 20:59 yes it makes sense to keep status quo. Once the spec is approved we will also need to make sure we replace old documentation to avoid confusion. 21:00 ilvipero: sorry, we're having two different discussions at once :-/ 21:00 and technically meeting time is over :P 21:00 any of us have a hard stop? 21:00 kicking myself out then :) 21:00 I'm fine with the archive policy moving to ubuntu-project-docs FWIW. Someone just needs to do it. Preferably keeping the text the same, then changing it by TB-reviewed PR later if warranted. 21:01 And then perhaps delete the ubuntu-policy package 21:02 yeah i don'ot have an issue with archive policy moving, but i don't think the actual definition of multiverse itself has changed even since that early SGML document 21:02 so at this point it's just wording and clarification therein 21:03 sigh session crashed 21:03 RIP 21:03 i think we can move ongoing discussion on this then to ML or elsewhere since we've exhausted our scheduled meeting time 21:04 i can't remember if the packaging guide is planned to move into the project docs or not 21:04 anyway yes, let's end the meeting, can talk about this sort of thing next time 21:04 #info Further discussion required 21:04 #topic Next meeting date, time 21:05 that should be 2025-12-02 at 20:00 London time if my scheduler is correct 21:05 if i'm wrong, we'll correct the agenda page :P 21:05 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)