20:05 <teward> #startmeeting Ubuntu Technical Board - 2025-11-18
20:05 <meetingology> Meeting started at 20:05:10 UTC.  The chair is teward.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
20:05 <meetingology> Available commands: action, commands, idea, info, link, nick
20:05 <teward> Hello hello!
20:05 <teward> #topic Action review
20:05 <teward> Gonna do these slightly out of order
20:05 <teward> #subtopic rbasak to reply to Mauro after 48 hours unless mwhudson objects
20:05 <rbasak> Done
20:06 <mwhudson> this was done i think
20:06 <teward> yay!
20:06 <teward> #subtopic rbasak to reply to mail about unity flavour on mailing list
20:06 <rbasak> I think that was done as well
20:06 <teward> nice, getting all the actino items out of the way
20:06 <teward> #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 <teward> 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 <teward> s/TB/CC/
20:07 <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: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 <teward> #subtopic seb, thomas, michael to provide feedback in "RFC: SRU Exception for transitional hardware enablements (tHWE)" thread
20:07 <mwhudson> i haven't done this yet :( i have done some thinking but not yet put the thoughts into an email
20:08 <rbasak> Frank replied to the ML today
20:08 <seb128> same, I did share a few though on the chat on the day of the previous meeting we didn't have
20:09 <rbasak> I don't think Frank has addressed any of my concerns. I can go into detail if it appears otherwise to you.
20:09 <mwhudson> frank is here if we want to talk about it live
20:09 <teward> i must have missed that message if it was recent.,
20:09 <teward> but yeah i saw fheimes here
20:09 <rbasak> I also don't follow what sort of exception is being requested here.
20:10 <fheimes> yes - I'm here
20:10 <rbasak> Surely it isn't just that if policy can't be met then we can ignore it?
20:10 <rbasak> So what is exceptional about this case that warrants an exception?
20:10 <rbasak> fheimes: hi! Feel free to speak :)
20:11 <rbasak> Also, why can't this be done in partner.canonical.com or in the OEM archive?
20:11 <fheimes> 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 <fheimes> "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 <mwhudson> partner.canonical.com does not exist in any meaningful way any more
20:11 <rbasak> mwhudson: so bring it back
20:11 <teward> #link https://lists.ubuntu.com/archives/technical-board/2025-September/003051.html
20:11 <teward> #link https://lists.ubuntu.com/archives/technical-board/2025-October/003055.html
20:11 <rbasak> Or use a PPA
20:11 <teward> #link https://lists.ubuntu.com/archives/technical-board/2025-November/003073.html
20:11 <teward> (adding for ML link reference in agenda)
20:12 <fheimes> partner.c.c is no longer
20:12 <rbasak> I believe PPAs are already being used for other "certified" hardware
20:12 <fheimes> the packages we talk about are asked to be in the archive
20:12 <rbasak> "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 <rbasak> Well, I disagree with that. You're only here because you *don't* want to live up to the usual Ubuntu standards.
20:13 <fheimes> PPAs come with some drawbacks, usability, visibility, and security maintenance
20:13 <rbasak> 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 <rbasak> fheimes: I disagree with basically all of that.
20:14 <rbasak> fheimes: usability is moot if users are downloading an image and then never doing a release upgrade as you claim.
20:14 <rbasak> Visibility is also moot for the same reason
20:14 <rbasak> 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 <rbasak> So it can all be done, and is already being done in other cases.
20:16 <fheimes> @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 <teward> also fheimes i want to put a huge caution flag on one thing you said:
20:16 <teward> > I would also expect that users follow common sense
20:17 <teward> **rule #1 of IT: assume the users are not going to follow common sense**
20:17 <teward> (rule #0 is "ALWAYS BACK UP YOUR DATA")
20:18 <teward> 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 <rbasak> fheimes: AFAIK, you're asking to add *new* packages into the archive, are you not?
20:18 <mwhudson> i think the packages are already there, in some cases
20:18 <rbasak> Which ones? Do we have a list of what is there and what is not?
20:18 <fheimes> please notice that the user set is different, these users are more commercial users
20:19 <rbasak> The SRU I rejected was for a new hardware enablement, not an existing one, AIUI.
20:19 <teward> fheimes: i'll save you my tirade about "the latest generation of corporation and commercial sysadmins" then.  (point still stands)
20:19 <rbasak> 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 <teward> ^^ that
20:20 <fheimes> @rbasak: there are multiple cases in flight - one could well be an existing package that should have received an hwe SRU
20:20 <rbasak> 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 <fheimes> well, it works on the certified ubuntu release (that is why certifications are done, no?)
20:22 <fheimes> quality is exactly what people look at when they perform a certification of a certain board on a specific Ubuntu release
20:22 <rbasak> 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 <teward> that is to say, a real-world example where this would be needed and where this claim is based on
20:22 <teward> rather than the generic 'hypotheticals' not clearly defined in your claims
20:22 <teward> (to build off rbasak's request)
20:23 <mwhudson> 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 <rbasak> 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 <rbasak> Did that change?
20:24 <fheimes> I think the tHWE gDoc references a more detailed doc that mentions and discusses several real world examples
20:24 <teward> fheimes: i will  caution that you link in that document to a 'tl;dr' document that nobody has access to
20:24 <rbasak> I don't have access to that.
20:24 <mwhudson> i don't know but i'm fairly sure that releases between the LTS and devel do not get enabled
20:24 <teward> fheimes: so you actually *haven't* given us that information we need to properly view those cases, etc.
20:25 <mwhudson> rbasak: yes you do, the doc is public
20:25 <mwhudson> oh wait, which doc is it
20:25 <teward> > Further details, tl’dr: Special package / archive cases in PE
20:25 <teward> ^^ this doc E:NOACCESS
20:25 <rbasak> Nope
20:25 <rbasak> Not working for me.
20:25 <teward> *that* gives the details on the special cases, etc you're referring to
20:25 <teward> **that** is not a public document
20:25 <teward> tHWE proposal without details is, but not the linked document in that
20:26 <seb128> > 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 <seb128> I don't think that was the case
20:26 <fheimes> 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 <seb128> 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 <fheimes> the tHWE gDoc is considered a summay
20:26 <rbasak> 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 <teward> 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 <teward> we need details, actual cases for analysis, etc.
20:27 <teward> as it stands it's not fully clear, at least to me, what cases the proposal would cover / apply to
20:27 <rbasak> seb128: mainline meaning upstream or Ubuntu devel?
20:27 <teward> and as rbasak mentioned, we'd *like* such details to actually evaluate better the claimed scenarios
20:28 <fheimes> teward: it is already shared by anyone with the link
20:28 <teward> 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 <teward> it won't give us access because the raw share link isn't embedded.
20:29 <seb128> rbasak, Ubuntu devel & upstream
20:29 <teward> fheimes: (I requested access *to* the document for this case thougH)
20:29 <seb128> sometime things are just not ready/quality enough to be in the main archive
20:30 <teward> #link https://docs.google.com/document/d/1libyBHG7hV9PmIi-5M-jJZV8KxfxLlX6HR7iLTatCvE/edit?tab=t.0#heading=h.vuwb4i3hth1q
20:30 <fheimes> please note that we shouldn't have been in this situation in the first place and look for a solution afterwards
20:30 <fheimes> but since we are there, we need to find a way to get unblocked
20:30 <fheimes> mid and long term all packages with all patches needed should be in all Ubuntu releases - that approach didin't change
20:31 <rbasak> 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 <rbasak> any justificatoin today.
20:32 <rbasak> fheimes: can you make the specifics public, please?
20:32 <teward> 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 <teward> where "later release" is either an existing stable release after a given release but not before the development release
20:32 <rbasak> 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 <fheimes> it is public already
20:32 <teward> fheimes: **no it is not**
20:33 <teward> if you aren't going to give us a direct share link for this
20:33 <teward> then it's not public
20:33 <teward> because that's not how gDocs work
20:33 <mwhudson> fheimes: "Special package / archive cases in PE" is not public
20:33 <teward> ^^ this
20:33 <rbasak> I have yet to see a list of packages and functionality you're using to justify your position.
20:33 <teward> 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 <rbasak> Maybe we need to move on?
20:34 <mwhudson> yes i'm not sure there's much value in more real time discussion
20:34 <seb128> 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 <fheimes> 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 <mwhudson> oh. that is not the link in the summary document
20:35 <teward> fheimes: that link is not in the summary document as a link
20:35 <mwhudson> (somehow)
20:35 <seb128> I can confirm that this link works in a private browser instance
20:35 <teward> the other document is *emedded* as an Google Documents integration/link
20:35 <teward> not a public share link
20:36 <teward> #link https://docs.google.com/document/d/1yLb1sUa6gXTT8BKe5vBDmK5AtQKfDA75G4MEpdi1Ir0/edit?tab=t.0#heading=h.sgumsf200jh5
20:36 <fheimes> that is the summary dog: https://docs.google.com/document/d/1libyBHG7hV9PmIi-5M-jJZV8KxfxLlX6HR7iLTatCvE
20:36 <fheimes> s/dog/doc
20:37 <fheimes> (and I see people having it open ...)
20:38 <rbasak> That works, thanks.
20:38 <fheimes> anyway, it is probably to long to read it now - on the fly (that was the reason for the sum. doc)
20:39 <rbasak> 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 <rbasak> AFAICT, you're asking for new hardware enablements in these SRUs only.
20:39 <rbasak> And I'm not aware that bug fixes for existing functionality is being blocked in SRUs at all.
20:40 <fheimes> I would need to go through the squads that work on the different platforms to filter for that
20:41 <rbasak> OK
20:41 <rbasak> So let's postpone further discussion I guess
20:41 <fheimes> but it's both fixes/maintenance and hwe
20:41 <teward> #info Requires further discussion and a potential future agenda item for further discussion
20:42 <teward> i'll table this for now so we can have further discussion and information provided
20:42 <teward> 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 <teward> (or plan specific meeting times for this discussino)
20:43 <teward> #topic Scan the mailing list archive for anything we missed (standing item)
20:44 <teward> going back the past couple months I see LTS requalification submissions are still coming into the TB
20:44 <teward> 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 <teward> and save for Frank's reply on the tHWE thing, there's nothing else in the November archives I'm aware of
20:44 <mwhudson> yeah i don't think that email warranted a reply iirc
20:44 <teward> yeah i glanced and didn't think it did
20:45 <teward> #topic Check up on community bugs and techboard bugs (standing item)
20:45 <rbasak> On the LTS requalification
20:45 <rbasak> I did ask here: https://lists.ubuntu.com/archives/ubuntu-release/2025-July/006430.html
20:45 <rbasak> I think some process and documentation changes are needed to get this going smoothly.
20:45 <teward> rbasak: i think we should prod the release team then
20:45 <teward> and get a reply
20:45 <rbasak> I'll reply to my reply
20:46 <teward> #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 <teward> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
20:46 <teward> 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 <rbasak> (email sent)
20:46 <rbasak> Sure
20:46 <seb128> how do we deal with flavor LTS qualifications request? not worth discussing here?
20:47 <teward> 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 <rbasak> 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 <teward> we also only have 13 minutes and mwhudson put something else on the agenda
20:47 <mwhudson> my thing is not very important
20:47 <teward> #info rbasak is next chair, with seb128 as backup (unless otherwise noted in agenda page)
20:47 <seb128> ah, right
20:47 <mwhudson> well it might spin off some discussion but it's not _urgent_
20:48 <teward> #topic AOB
20:48 <teward> now we can talk about LTS requalifications stuff :0
20:48 <teward> (just wanted to get to that topic XD)
20:48 <teward> #subtopic LTS requalification requests and processes
20:49 <teward> right now because no other process has been published anywhere, everyone's using the old ones
20:49 <teward> that requalifications go via us - TB
20:49 <rbasak> Right.
20:49 <teward> 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 <teward> as soon as that is published and ACK'd by us then Release Team takes charge
20:50 <teward> 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 <teward> s/policies/processes/
20:50 <teward> 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 <teward> so i think we'll just have to wait for a reply in this case?
20:52 <rbasak> I think so yes
20:52 <seb128> yes
20:52 <teward> awesome
20:52 <mwhudson> where is the existing process documented? is it still on the wiki?
20:52 <teward> #info Awaiting more info from release team on how they'd like this process to work
20:52 <mwhudson> https://wiki.ubuntu.com/RecognizedFlavors and related pages?
20:53 <rbasak> There's also the upcoming flavour spec work
20:53 <rbasak> Which AIUI will replace the wiki docs
20:53 <mwhudson> ah right yes that can of worms
20:53 <rbasak> ilvipero: ^
20:54 <teward> with only five minutes left effectively, we may have to bring that up for future discussion
20:54 <mwhudson> although the current spec doesn't talk about LTS qualification in detail from a very quick skim
20:55 <mwhudson> 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 <teward> 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 <teward> #subtopic (mwhudson) what can go into multiverse https://github.com/ubuntu/ubuntu-project-docs/pull/309
20:56 <teward> i see Robie already replied on the PR mwhudson did you review and reply?
20:56 <teward> ... at least I think that's Robie
20:56 <rbasak> Yes
20:57 <ilvipero> Thanks for the ping, yes I have planned time with Utkarsh to discuss this topic in the flavor spec.
20:57 <mwhudson> 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 <rbasak> 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 <rbasak> mwhudson: sure, but it is the status quo until then IMHO.
20:59 <teward> 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 <teward> (this IS the packaging guide after all)
20:59 <rbasak> (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 <ilvipero> 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 <rbasak> ilvipero: sorry, we're having two different discussions at once :-/
21:00 <teward> and technically meeting time is over :P
21:00 <teward> any of us have a hard stop?
21:00 <ilvipero> kicking myself out then :)
21:00 <rbasak> 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 <rbasak> And then perhaps delete the ubuntu-policy package
21:02 <teward> 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 <teward> so at this point it's just wording and clarification therein
21:03 <mwhudson> sigh session crashed
21:03 <teward> RIP
21:03 <teward> i think we can move ongoing discussion on this then to ML or elsewhere since we've exhausted our scheduled meeting time
21:04 <mwhudson> i can't remember if the packaging guide is planned to move into the project docs or not
21:04 <mwhudson> anyway yes, let's end the meeting, can talk about this sort of thing next time
21:04 <teward> #info Further discussion required
21:04 <teward> #topic Next meeting date, time
21:05 <teward> that should be 2025-12-02 at 20:00 London time if my scheduler is correct
21:05 <teward> if i'm wrong, we'll correct the agenda page :P
21:05 <teward> #endmeeting