== Meeting information == * #ubuntu-meeting: Technical Board meeting, started by seb128, 20 May at 19:03 — 20:01 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2025/ubuntu-meeting.2025-05-20-19.03.log.html == Meeting summary == === Action review === Discussion started by seb128 at 19:03. * ''LINK:'' https://www.debian.org/vote/2025/vote_002 (rbasak, 19:09) * ''ACTION:'' seb128 to read up on Open Source AI Definition and consideration of proposal to endorse the definition. (seb128, 19:17) * ''ACTION:'' TB to vote on the proposal at the next meeting (seb128, 19:19) * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2024-January/002862.html (seb128, 19:21) * ''ACTION:'' mwhudson to remove the TB from ~launchpad-buildd-admins (seb128, 19:24) * ''ACTION:'' rbasak to reply to the release team and clarify the LTS flavor delegation process (seb128, 19:30) * ''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 (seb128, 19:31) * ''ACTION:'' teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (seb128, 19:34) * ''ACTION:'' teward to write up a proposal for how the move away from the wiki will work (seb128, 19:34) === Should we endorse the Open Source AI Definition? === Discussion started by seb128 at 19:39. === [rbasak] DMB election planning === Discussion started by seb128 at 19:39. * ''ACTION:'' rbasak to run the DMB election (seb128, 19:41) === Scan the mailing list archive for anything we missed (standing item) === Discussion started by seb128 at 19:41. * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2025-May/003016.html (seb128, 19:42) === Official status of riscv64 === Discussion started by seb128 at 19:43. == Action items, by person == * mwhudson * mwhudson to remove the TB from ~launchpad-buildd-admins * rbasak * rbasak to reply to the release team and clarify the LTS flavor delegation process * rbasak to run the DMB election * seb128 * seb128 to read up on Open Source AI Definition and consideration of proposal to endorse the definition. * 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 * teward * teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC * teward to write up a proposal for how the move away from the wiki will work * **UNASSIGNED** * TB to vote on the proposal at the next meeting == People present (lines said) == * rbasak (82) * seb128 (78) * teward (65) * mwhudson (30) * meetingology (10) * mdeslaur (3) == Full log == 19:03 #startmeeting Technical Board 19:03 Meeting started at 19:03:40 UTC. The chair is seb128. Information about MeetBot at https://wiki.ubuntu.com/meetingology 19:03 Available commands: action, commands, idea, info, link, nick 19:03 #topic Action review 19:04 yes 19:04 here 19:04 * teward was mid-biobreak 19:04 * seb128 Remaining TB members (teward, mwhudson, seb128) to read up on Open Source AI Definition and consideration of proposal to endorse the definition. 19:04 i have actually read this now! 19:05 I still didn't, things have been busy, sorry :-/ 19:05 i haven't fully read it. but i'm +/- 0 on it because I think our endorsement has benefits *and* detriments 19:05 and is a Catch-22 that can come back to bite us if we're not careful. 19:06 how do we want to handle that topic? is it fit for a 1h meeting? 19:06 my take is that something meeting the open source ai definition would not meet my understanding of the requirements for something being included in the archive (but also that this was not the intention of our endorsement) 19:06 The discussions in Debian on this topic continue, FWIW 19:07 yeah there is a GR being proposed on this? 19:07 Yes it's going through the process AIUI, although not at voting stage yet 19:07 i also feel like ubuntu doesn't gain much from endorsing this definition? 19:07 IMHO, any endorsement by Ubuntu *should* affect our position on acceptability into the archive. 19:08 and also also that perhaps the debate about what "open source ai" means is a bit less hot than it was when when the OSAID was drafted 19:09 I agree on the fact that endorsement or not should affect what we do for the archive 19:09 I also leaning towards thinking that it's fine for us to take a stronger position, such as that proposed in Debian, but be pragmatic about making models that don't meet that standard available to our users easily regardless 19:09 https://www.debian.org/vote/2025/vote_002 19:09 "AI models released under DFSG-compatible license without original training data or program" are not seen as DFSG-compliant." 19:09 That's currently the only option in the GR, though IIRC that might change. 19:11 so none of us are leaning towards endorsement, it seems 19:11 So I wrote my opinion to the list a while ago 19:12 To make progress, subject to teward and mwhudson's opinions, I wonder if we could: 1) take the view (as the TB) that any endorseement we may choose to make on this topic should apply to the archive 19:13 2) defer consideration on endorsing OSAID until the Debian process is complete 19:13 Alternatively, we might wish to be bolder, but I don't see any appetite for that from TB members on the ML thread. 19:14 i think i agree with this 19:14 FTR, I am leaning towards rejecting OSAID in the future, in favour of what's in Debian's GR choice 1 at the moment. 19:14 But I could be swayed. 19:14 I should be able to catch up on the topic and have an opinion by the next meeting now that release, holidays Canonical travel etc are behind 19:15 seb128: OK, so shall we consider my proposal above as concrete, to be voted on by the TB at the next meeting? 19:15 i am also open to arguments against 1) but i don't really see any at the moment 19:15 rbasak, +1 from me 19:17 mwhudson, teward, +1 / 0 / -1 on rbasak's proposal? 19:17 +1 19:17 ok, great 19:17 reading. (half split with a meeting) 19:17 You're asking to vote on a proposal for a proposal? o_O 19:17 agree with proposal. 19:17 #action seb128 to read up on Open Source AI Definition and consideration of proposal to endorse the definition. 19:17 * meetingology seb128 to read up on Open Source AI Definition and consideration of proposal to endorse the definition. 19:18 ...consideration of proposal to *defer* endorsing the definition, to be clear. 19:19 #action TB to vote on the proposal at the next meeting 19:19 * meetingology TB to vote on the proposal at the next meeting 19:19 * seb128 mwhudson to propose course of action around techboard membership of buildd admins 19:19 Oh, I see, sorry. 19:19 rbasak, sorry for being unclear, I just carried the old item for myself before adding the new action 19:19 mwhudson, ^ buildd? 19:20 i tried to dig into the history but didn't find anything 19:20 seb128: no my mistake - I understand now. 19:20 my inclination is to just remove us 19:20 mwhudson, I shared the history in the last TB meeting where we discussed it IIRC? 19:21 https://lists.ubuntu.com/archives/technical-board/2024-January/002862.html 19:21 that's about ownership not membership 19:21 ah, right, sorry 19:23 I'm fine with removing us - as long as whoever does it deals with any fallout please/ 19:23 I've no strong opinion 19:23 (AIUI the chance of fallout is considered to be low) 19:23 ok so i'm ok to act on removal? 19:23 +1 19:24 +1 from me, as Robie said, if there are unexpected fallout we can deal with those 19:24 +1 as indicated. 19:24 #action mwhudson to remove the TB from ~launchpad-buildd-admins 19:24 * meetingology mwhudson to remove the TB from ~launchpad-buildd-admins 19:25 * seb128 rbasak to follow up on https://lists.ubuntu.com/archives/ubuntu-release/2023-December/005859.html with the release team. 19:25 Response here: https://lists.ubuntu.com/archives/ubuntu-release/2025-May/006417.html 19:25 If the TB agrees that we can consider it done? 19:26 I'm not sure if there's any documentation action 19:26 Do we have any existing documentation on the topic? 19:27 Not that I'm aware of. I imagine that the release team can keep track of things and make recommendations to the TB (the ML will do for now) as/when needed. When a recommendation arrives, we can consider at our next meeting. 19:27 i think this makes sense overall 19:27 I'm happy to follow up on the list to clarify that process. 19:28 the lack of documentation is relevant to the installer topic ... 19:28 it feels like we should have the process documented, unsure if that is a TB topic though... 19:29 I can ask in my reply to the release team 19:29 ok, thanks 19:29 do you want an action item for it or is that not needed? 19:29 IMHO it could be a TB topic as part of us documenting what we have delegated to teams and what our expectations are from those delegates 19:29 Sure, give me an action plesae 19:30 Are we agreed that we're happy to continue in this direction? 19:30 #action rbasak to reply to the release team and clarify the LTS flavor delegation process 19:30 * meetingology rbasak to reply to the release team and clarify the LTS flavor delegation process 19:30 I agree yes 19:31 and seems like mwhudson is as well, so let's move on, we have other topics 19:31 * seb128 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:31 yep 19:31 still being worked on... 19:31 #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:31 * 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:31 * seb128 teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC 19:32 i brought it up with the CC but we've had some... larger problems... we've been dealing with that made this a lower-priority issue for the CC. 19:32 internally we've documented things we learned from this TB election cycle already regarding who can do what, etc. with regards to applicants, etc. 19:32 and clarified with Mark as well 19:32 but we haven't updated the documentation and such yet 19:33 (because of Other Issues (TM)) 19:33 Sounds like progress - thank you! 19:33 so carrying over until that is done? 19:33 (other issues appreciated) 19:33 and thanks for the update! 19:33 i think we can carry it over because it's incomplete but we might make that a progress report item for next one 19:33 happy to hear some progress is being made! 19:34 (those of you Who Know, know what the Other Issues were) 19:34 #action teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC 19:34 * meetingology teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC 19:34 * seb128 teward to write up a proposal for how the move away from the wiki will work 19:34 yeah that's still needed. 19:34 so carry that one over 19:34 #action teward to write up a proposal for how the move away from the wiki will work 19:34 * meetingology teward to write up a proposal for how the move away from the wiki will work 19:35 * seb128 tsimonq2 to study "look into scripting for packages in flavor-specific overlays" from https://irclogs.ubuntu.com/2024/02/13/%23ubuntu-meeting.html#t20:24 and suggest to the TB what needs doing there 19:35 I think we can drop that one? 19:35 yes 19:35 on that btw 19:35 i know it was said privately 19:35 I think we need to drop it now, yes 19:35 The matter is still open for anyone to take - it does not require privilege to make progress on this, and I'm sure flavours would appreciate it. sgmoore especially at the moment I think. 19:36 i admit i never quite understood what this was about but clearly it's not going to progress in the current form 19:36 but Simon's not allowed to participate in the project until late April of next year. Again, referring to the Other Issues I mentioned, it's something that needs dropped if it's in Simon's lap unless someone else wants to take over. (we could leave it as unassigned) 19:36 I'm not in favor of having unassigned items on the agenda 19:36 just putting it there as an aside. i agree we can drop it ifor now 19:37 The root of the matter is that the automatic seeds/germinate -> flavour packageset mechanism is broken and requires overhaul. In the meantime, non-MOTU non-coredev flavour packageset uploaders are being hindered. 19:37 we probably have a stack of things that could be done, and it might be worth maintaining a wishlist somewhere for those who want to help though 19:37 This isn't really a TB matter FWIW 19:37 ^^ that 19:37 it's not a TB matter necessarily 19:37 Packageset (for upload permission) management is delegated to the DMB 19:37 right 19:38 But it's also only under the DMB's authority. Anyone can propose a fixed script and the DMB will review it. 19:38 right 19:38 i think it makes sense to drop this from our agenda for now. if someone else thinks it is a TB issue for whatever reason they can add it again ... 19:38 +1 19:38 ok, let's move on and try to discuss the other topics 19:38 yup 19:39 #topic Should we endorse the Open Source AI Definition? 19:39 we already discussed that 19:39 #topic [rbasak] DMB election planning 19:39 Agreed 19:39 DMB elections are due imminently, and they are (technically) run by the TB. 19:40 I propose to run them again as I have for the past six years or so - I have the process fine tuned (and fully documented!) 19:40 I haven't discussed this with the DMB yet due to meeting timing. 19:40 rbasak: i might pick your brain then on how to run an election for with CIVS, etc. because Lubuntu reasons just a heads up 19:40 May I have the TB's authority to run the DMB election again, subject (if you like) to not having any objections from existing DMB members? 19:40 but yeah i think it's time for a DMB meeting, since DMB is also down a member with Simon barred. 19:40 +1 on rbasak running the dmb election from me 19:41 rbasak: +1 from me 19:41 s/DMB Meeting/DMB election/ 19:41 +1 19:41 teward: https://git.launchpad.net/~ubuntu-dev/+git/election-tools/tree/ should have everything you need 19:41 Thanks! 19:41 #action rbasak to run the DMB election 19:41 * meetingology rbasak to run the DMB election 19:41 rbasak: thanks 19:41 #topic Scan the mailing list archive for anything we missed (standing item) 19:42 https://lists.ubuntu.com/archives/technical-board/2025-May/003016.html 19:42 There's also: 19:42 Official status of riscv64 (mwhudson) 19:42 That was at the top of the agenda 19:42 ah, right 19:42 But there's also an ML thread :) 19:42 ah, sorry 19:43 let's do the riscv quickly 19:43 I think my only question on the installer thing was whether or not the designated individuals at Canonical (Jon) have read all the responses from the various flavors and relevant councils, etc. 19:43 then go back to installer which is probably longer 19:43 oop i was still on the installer we can switch to riscv 19:43 #topic Official status of riscv64 19:43 teward, sorry :) 19:43 mwhudson, yours 19:43 * teward sends seb128 to /dev/null for a few CPU cycles :P 19:43 lol 19:44 so the conclusion from the thread was that the official flag has no technical meaning, it's purely cosmetic 19:44 On riscv64, we don't have a definition of what "official" means, and AFAIK, never have done. 19:45 I agree it appears to be purely cosmetic 19:45 But apparently people care 19:45 "cosmetic", it still somehow give a signal 19:45 now there are some practical distinctions between riscv64 and other arches: security updates can be delayed and we don't run as many tests (build time tests are disabled, autopkgtests are not blocking) 19:45 Right 19:45 i think this belies an underlying issue - we have no definition for "official" - should we be focusing on what we define "official" to be first? 19:46 also excuse typos i'm typing with one hand at the moment 19:46 otoh, it is an architecture we take seriously, it's definitely more $something than say hppa was 19:46 And if there are issues with the architecture not being a first class citizen in our infrastructure, causing actual practical problems for Ubuntu development and development velocity, then it might make sense for us to define "official" as not having those issues, to avoid sending a poor signal? 19:47 I personally would expect an official architecture to get security updates in time and to run the standard set of tests 19:48 More generally, I think there are two things: 1) it is treated the same as other architectures eg. blocking proposed migration, FTBFS in main is a problem, etc, and the release team think it's ready; and 2) practical developer experience with the arch is on par with the others, in the opinion of Ubuntu developers. 19:48 I think the TB should consider 1 delegated to the release team, but it might be appropriate for the TB to consider 2 directly. 19:48 do you have any example of 2) 19:48 seb128: I agree 19:49 i think a question i had is *why* were updates delayed and why the tests and such are not run or not blocking. if we want to hold it to the same as other archs, there's some things to discuss on that 19:49 What I have in mind as an example of 2 is my report of waiting days for proposed migration due to riscv64 build queues, and mdeslaur's concern about security updates - both reported in the ML thread. 19:49 i do agree 1 to be delegated to Release Team, but I still want to know what the delays are for Security, etc. 19:49 teward: i think it's 100% that the builders are slower (because emulated) 19:50 mwhudson: yes, but also, more of them would help in practice 19:50 (I didn't see a clear answer in the ML items hence my statement) 19:50 IIUC? 19:50 (and emulated builders are going to continue to be a thing for a while, practically speaking, but hopefully we can throw more hardware at the problem) 19:50 rbasak: is there a reason we don't have *more*? If the issue is because IS doesn't have the resources or time, etc. then we need to be pressuring IS (who already is overwhelmed with a ton of things) 19:50 teward: exactly 19:51 teward: and I think if there's a practical development issue blocked on resources like that, then declaring it "official" as if it's on par with the others would be sending a false signal. 19:51 i agree with you on that 19:51 Now, what the bar should be exactly is subjective of course. We might agree with the principle, but consider the bar to be met. 19:52 so maybe the next step is to make some enquiries about future hardware plas? 19:52 (gosh this meeting time sucks for me) 19:52 mwhudson: we could, but I'd like to delegate that to the people who care. 19:52 rbasak: i think then that falls to the Release Team to make a decision, not the TB 19:53 teward: you bring up a good point. I'm on the fence. 19:53 here's my opinion on this and why i'm not going to +1 making it official: 19:53 The TB could say: "RT: TB thinks you should consider the quality bar, but we delegate that decision to you". 19:53 (1) 19:53 Security updates are delayed because of hardware/resource 19:53 Or the TB could say: "TB thinks the quality bar isn't being met; do better, than ask us again" 19:53 (2) We don't run the same tests on the arch because of resources for autopkgtests, etc. 19:54 rbasak: or we could say: 19:54 I guess release team would make sense, they assert the state of the release 19:54 ... oop your second one is accurate 19:55 s/than/then/ 19:55 that's what i was gonna say. but i'm thinking that the quality bar still isn't met for riscv ONLY because of IS and not enough infra being dedicatded to riscv64 19:55 teward: ^ agreed 19:55 (at least I agree that's how it appears to me) 19:55 i think since it's really a Release Team issue, we should tell them that it's really a decision that we delegate to you,but strongly consider the following as a quality bar: ... 19:55 my 2 cents 19:56 i have to drop at the hour 19:56 (i'm -1 on it being official without timely Security updates and same test loads) 19:56 (ftr, it's not only about number of builders, it's also about build speed...when I have to release an emergency regression fix and it takes 45m on amd64 and 5 hours on riscv64, I release without riscv64) 19:56 (but I believe it's an RT decision not ours) 19:56 teward: you cannot be -1 on it if you're also delegating the decision to the RT. 19:56 Well, you can state an opinion of course :) 19:56 rbasak: well if the vote is "TB should decide", then -1 on official. But if we delegate it to the RT that's a susperseding decision 19:56 mdeslaur, that's a good point 19:57 Thanks mdeslaur. So that's something that cannot be fixed, AIUI 19:57 (with mere resources) 19:57 mwhudson, I guess we will discuss the installer offline of next time... 19:57 or 19:57 lets discuss the installer issue either at a separate adhoc or on ML 19:57 mdeslaur: do you have an opinion on whether the bar is met currently, and/or whether the release team should be delegated the decision? 19:58 Asking because the security team's opinion is important here, and is distinct from the RT. 19:58 TB members: where do you stand on the TB deciding vs. delegating to the RT? 19:58 (I'm still undecided) 19:58 I believe that having riscv64 build more slowly than the other archs is the nature of the arch, and it's not something we can fix. The security team will add a disclaimer to our wiki page about riscv64 possibly having delayed updates. 19:59 ack, thanks 19:59 with that disclaimer, I have no objection to the flag being set 19:59 I wonder if we need to defer any decision on this until the next meeting 19:59 i'm undecided as well specifically on whether it's our decision or delegating. evidenced by the fact i have split opinions 19:59 (which FWIW I'm not sure I can make) 19:59 rbasak: we can always reschedule if we have to, i now mwhudson has problems with this time slot) 19:59 I'm slightly in favor of delegating to the RT 20:00 sounds like further discussion required. maybe we can make progress on the mailing list? 20:00 +1 for ML 20:00 +1 20:00 i have to go now. see on on the ml 20:00 +1 for ML 20:00 we are at the end of the hour 20:00 same for installer +1 to ML 20:00 i'm being called by my boss so I have to disappear as well 20:00 (at dayjob) 20:00 teward, to reply to your question from earlier, I'm unsure people had time to catchup with the Canonical sprints 20:01 but we should, I will check on that this week 20:01 seb128: wrt installler? 20:01 yes 20:01 ack 20:01 wasn't sure which "earlier question" you were referring to ;) 20:01 thanks 20:01 <teward> I think my only question on the installer thing was whether or not the designated individuals at Canonical (Jon) have read all the responses from the various flavors and relevant councils, etc. 20:01 this one 20:01 yep :) 20:01 and on that note wrapping, thanks! 20:01 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)