19:18 <seb128> #startmeeting technical board
19:18 <meetingology> Meeting started at 19:18:27 UTC.  The chair is seb128.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
19:18 <meetingology> Available commands: action, commands, idea, info, link, nick
19:18 <seb128> #topic action review
19:19 <seb128> #subtopic teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over)
19:19 <teward> carry over
19:19 <teward> i'm here, but i was on a call with the Big Boss CEO guy who pays my bills at $DAYJOB :p
19:19 <teward> can't say no to those calls
19:19 <seb128> ack
19:20 <seb128> #action teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over)
19:20 * meetingology teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over)
19:20 <seb128> #subtopic seb128 to continue working with AA and Release teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations
19:21 <seb128> carrying over (might make sense to delete it from the agenda though, I'm continuing to persue it but as a background task so it keeps being carried over)
19:21 <seb128> #action seb128 to continue working with AA and Release teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations
19:21 * meetingology seb128 to continue working with AA and Release teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations
19:21 <seb128> #subtopic seb128 to discuss requiring email to ubuntu-devel before ubuntu-only package introduction idea with AAs
19:22 <seb128> so we did discuss it at the Archive Admin meeting
19:22 <teward> seb128: regarding "might make sense to delete it from the agenda" we could put it in a category of items we know oare on the radar but we don't bring up every time
19:22 <teward> (like 'known standing items'
19:22 <seb128> that would make sense I guess
19:22 <seb128> +1 from me ... rbasak / mwhudson , opinion  on that?
19:23 <mwhudson> yeah, just carrying things over endlessly seems like makework
19:23 <mwhudson> they could be techboard bugs i guess, and get covered in that section of the meeting?
19:23 <seb128> k, I will do that edit when I refresh the page at the end of the meeting
19:24 <seb128> that would also work
19:24 <seb128> that might be even better since that would let a place for status updates etc
19:24 <rbasak> Sorry, you said you did discuss it?
19:24 <rbasak> So what was the outcome?
19:25 <seb128> sorry, I got sidetracked by adressing the comment about the previous point
19:25 <seb128> I plan to go back to the topic
19:25 <seb128> do we want to finish that ^ discussion first or maybe push to AOB if needed?
19:26 <mwhudson> chair decides :-)
19:26 <rbasak> Yes - sure
19:27 <seb128> ok, let's push to AOB if there is more, I'm personally happy to track those as bugs but we can discuss over that at the end if anyone is interested/have a different opinion
19:27 <seb128> so, new packages
19:27 <seb128> our current documentation is https://canonical-ubuntu-project.readthedocs-hosted.com/staging/new-packages/
19:27 <seb128> it states "To get a package into Ubuntu, please file a bug in Launchpad and make sure it has the tag needs-packaging."
19:28 <seb128> that is more for sponsoring of new packages atm
19:28 <seb128> but AA believe that launchpad with a defined tag is a better place
19:28 <seb128> and would happily review a PR against that documentation page from anyone want to propose a change
19:29 <rbasak> That would work, since it's possible to subscribe to a particular bug tag.
19:29 <rbasak> Would the AAs be willing to _enforce_ this though, by not accepting a package unless it has a bug reference with the given tag?
19:29 <seb128> right, and we believe that launchpad is a better suited place and also the natural one to provide comments at the time of the NEW review anyway so having a bug is desirable
19:30 <mwhudson> i don't do much NEW review in practice but i certainly dislike doing it when there is no bug to provide feedback on
19:30 <seb128> the general feeling was that it is a good practice and should be strongly recommended
19:30 <rbasak> That sounds good to me. So I suppose the next step is to propose the docs change
19:30 <rbasak> (and maybe start a thread on ubuntu-devel@ once that's filed)
19:30 <seb128> there wasn't consensus on enforcing it as an hard requirement though, but we said that nuance can be discussed in the PR
19:32 <rbasak> OK
19:32 <seb128> so, anyone wanting to do the next step and take an action to draft the PR?
19:32 <rbasak> I don't mind taking the action, but it might be a few weeks before I get to it
19:32 <seb128> draft / do an initial proposal
19:33 <rbasak> Maybe put it in your new "standing items" section :)
19:33 <seb128> I think that's fine, realistically that would probably be the same for me / others TB members
19:33 <seb128> sounds good :)
19:34 <seb128> #ACTION (for the new TBD section) rbasak to draft a PR proposal for the "NEW packages should have a tagged bug on launchpad" policy
19:34 * meetingology (for the new TBD section) rbasak to draft a PR proposal for the "NEW packages should have a tagged bug on launchpad" policy
19:35 <seb128> #topic Scan the mailing list archive for anything we missed (standing item)
19:35 <seb128> https://lists.ubuntu.com/archives/technical-board/2025-August/date.html
19:35 <seb128> nothing new since
19:35 <seb128> #topic Check up on community bugs and techboard bugs (standing item)
19:36 <seb128> https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard empty
19:36 <seb128> https://bugs.launchpad.net/techboard
19:36 <seb128> no recent activity there
19:36 <seb128> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
19:37 <seb128> going in order that would be teward chair and mwhudson as backup
19:37 <seb128> any objection?
19:37 <mwhudson> my clocks change this weekend so the meeting will be at 8am, which is kind of a pain. we can see how it goes!
19:39 <seb128> I don't remember what we said for UTC or London  time
19:39 <seb128> I think usually we sticked to London/Europe time so it would shift next month
19:40 <mwhudson> if it is pegged to uk time, when the uk clocks change it will be 9am, which is fine
19:40 <seb128> right
19:40 <seb128> that also works better for me, unsure for teward and rbasak
19:40 <mwhudson> it's just this interval between my clocks changing and europe that is hard (my favourite time of year)
19:40 <seb128> right...
19:40 <rbasak> I'm not sure I follow exactly what you're suggesting.
19:41 <rbasak> Currently we're on 1900 UTC.
19:41 <seb128> I think historically the meeting time as contant along the year on London/European time
19:41 <seb128> it would become 20UTC in winter
19:41 <rbasak> I'm fine with that
19:41 <seb128> k, let's do that then :)
19:41 <seb128> and moving on
19:41 <rbasak> So we're switching to 2000 Europe/London, right?
19:42 <seb128> usually at European DST, so not yet for the next meeting
19:43 <mwhudson> rbasak: i don't think that's actually a change. i wasn't meaning to propose a change, just pointing out that the next two meetings might be a bit difficult for me to pay full attention to
19:43 <seb128> the meeting just stick to London 8pm
19:44 <seb128> #topic AOB
19:44 <seb128> #subtopic fheimes put "SRU Exception for transitional hardware enablements (tHWE)"  as an AOB on the agenda
19:44 <seb128> https://docs.google.com/document/d/1libyBHG7hV9PmIi-5M-jJZV8KxfxLlX6HR7iLTatCvE
19:45 <rbasak> I didn't see this. Reading.
19:45 <rbasak> I'd appreciate if these things could be announced on the ML FWIW, but we're here now.
19:46 <seb128> fheimes pinged me about it before the meeting and said he should have sent on the ML and that maybe then we need to postpone the discussion for next time
19:46 <seb128> but since we have a bit of time left we can maybe start on the topic, I'm also reading the document now...
19:46 <rbasak> I'm OK to discuss this briefly now
19:47 <rbasak> I appreciate this being thought out and brought forward for consideration, thanks
19:47 <seb128> my first question would be: is that a TB topic or something the SRU team has delegated decision power on?
19:47 <juliank> It's outside of SRU delegation :D
19:48 <rbasak> I don't think the SRU has delegated decision powers on this, given my understanding of how the SRU's powers came to be, and how the TB has acted in the past in making decisions on these kinds of things.
19:48 <fheimes> I discusses that with SRU members, and some where unsure and suggested to bring that to the TB
19:48 <rbasak> I could go into detail if you like, but I wrote the SRU documentation with this assumption in mind, and it's never been challenged, including in other things that I have brought to the TB for consideration.
19:49 <mwhudson> my (vague) understanding is that the SRU team do not want to decide on this, even if they could
19:49 <seb128> I'm personally fine with that position, no need to detail further on why it's a TB topic I think
19:50 <seb128> and mwhudson seems to agree, so let's move on and look at the actual proposal
19:50 <rbasak> I appreciate the consideration of ubuntu-release-upgrader. It sounds like that sort of thing in principle avoids technical issues with upgrades.
19:50 <rbasak> I think the bigger question is about user expectations of these things.
19:51 <juliank> I want to note that I discussed the option thing with enr0n as u-r-u maintainers and we think that makes sense
19:51 <rbasak> For example, if a user hears that "Platform X is now officially supported and certified on Ubuntu", then will they be angry if they later find that a release upgrade doesn't work?
19:52 <juliank> FWIW; I believe that already happens with OEM hardware is my understanding; they prevent upgrades in the OEM archive, until the laptop has been recertified / known to work
19:52 <fheimes> these are mainly PE cases (Partner Engineering) and the PE documents usually where such optimized kernels are supported on
19:52 <juliank> But I don't _know_
19:53 <rbasak> "ensure they otherwise live up to the usual Ubuntu standards" is an interesting statement.
19:53 <mwhudson> there are all kinds of nuance here. hardware does get obsoleted (e.g. i386, the rva23 thing)
19:54 <juliank> POWER never survives an LTS cycle, basically
19:54 <juliank> So far it got a baseline bump each LTS IIRC
19:54 <seb128> there is also "in an ideal world yes it would work on any Ubuntu serie", but if that can't happen for $reasons, then what. Is it better to have a LTS working or no Ubuntu version working?
19:54 <mwhudson> would users care if they can update to the LTS but not to any interim release?
19:54 <rbasak> Consider https://bugs.launchpad.net/ubuntu/+source/linux-firmware-mediatek-genio/+bug/2112375
19:55 <mwhudson> otoh i don't know that the TB ever formally approved what the OEM team currently do :-)
19:56 <fheimes> @rbasak: yes, mediatek is indeed one example (one of a few)
19:56 <rbasak> d "supported" in Jammy, but with no intention to do in Noble until after Noble was released.
19:56 <rbasak> Apparently this was certified "supported" in Jammy, but with no intention to do in Noble until after Noble was released.
19:57 <fheimes> the long term goal and push (of PE) is to bring everything needed also into newer releases (be it interim or LTS)
19:57 <rbasak> I think a user being told "i386 is old and deprecated and no longer supported" and not being able to release upgrade such a system is very different to a user learning that some Mediatek hardware is now "supported" but then not being able to upgrade to the latest LTS.
19:57 <rbasak> IMHO, support not available *on release day* of the next LTS breaks user expectations there
19:57 <mwhudson> agreed ther eis a difference there
19:58 <fheimes> but notice that the expectation (in case of Mediatek and others) are documented
19:58 <juliank> The expectation should be that when 24.04.1 is out, it is supported, as that's when upgrades are enabled
19:59 <juliank> Provided there are users left
19:59 <rbasak> Maybe, but it means that users now have to be aware that if something is available in an Ubuntu LTS, they have no idea whether it will be available in the subsequent LTS, even if the hardware isn't obsolete, without actually checking.
19:59 <rbasak> juliank: point about the first point release taken
19:59 <juliank> Who actually uses partner engineering software?
19:59 <juliank> i.e. do partners (re)distribute it to users
19:59 <rbasak> juliank: however, users also do fresh installations on the basis of previous LTS support.
19:59 <juliank> or is it for partners' internal use?
20:00 <rbasak> juliank: so it's not just about breaking upgrades, it's also about setting user expectations about support
20:00 <fheimes> the partners and their and our customer
20:00 <juliank> Is it more like POWER, where we just bump the baseline each time and old hardware stops working?
20:00 <juliank> Or like a desktop, where users don't have a contract with their system supplier
20:00 <seb128> what's the reason why support can't be added to newer series?
20:01 <fheimes> well, we bump the baseline on several platforms over time: ppc64el, s390x, riscv - it's not unusual
20:01 <mwhudson> jul
20:01 <mwhudson> oops
20:01 <mwhudson> juliank: i think it's both, in practice
20:02 <fheimes> @seb128: can be manyfold - not accepted upstream yet, patches not forward ported, limited resources, test not completed, but even more
20:03 <juliank> binary drivers not yet provided for newer releass :D
20:03 <fheimes> juliank: yes, even this ...
20:03 <seb128> we are technically over the TB meeting time now, unsure how we want to continue that discussion...
20:04 <mwhudson> maybe we should suggest fheimes mails the list and continue discussion there?
20:04 <rbasak> +1
20:04 <seb128> +1
20:06 <seb128> ok, let's wrap there then
20:06 <teward> +1
20:06 <seb128> thanks everyone
20:06 <teward> o/
20:06 <seb128> #endmeeting