=== oerheks1 is now known as oerheks [14:29] good morning [14:30] o/ [14:30] \o [14:31] hey [14:32] sorry, multi laptop issues, should be ready to copypasta in a second ... [14:32] o/ [14:32] #startmeeting Weekly Main Inclusion Requests status [14:32] Meeting started at 14:32:32 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology [14:32] Available commands: action, commands, idea, info, link, nick [14:32] Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer mylesjp pushkarnk ( dviererbe ) [14:32] o/ [14:32] #topic current component mismatches [14:32] Mission: Identify required actions and spread the load among the teams [14:32] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:32] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:33] what do we have today ... [14:33] non-proposed is all fine [14:33] only usual suspects [14:33] and proposed only has the ruby-rack related [14:33] which IIRC Renan filed and joalif is reviwing [14:33] pasting the review as we speak [14:34] let me ask renan if rackup is also needed [14:34] done [14:34] Thanks joalif [14:34] #topic New MIRs [14:34] Mission: ensure to assign all incoming reviews for fast processing [14:34] #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir [14:35] we have one case [14:35] https://bugs.launchpad.net/ubuntu/+source/coreutils-from/+bug/2110879 [14:35] -ubottu:#ubuntu-meeting- Launchpad bug 2110879 in coreutils-from (Ubuntu) "[MIR] coreutils-from" [Undecided, New] [14:35] this is not yet the big chunk of rust coreutils [14:35] Julian talked to me about this during the sprint. It's a pro forma MIR (optional), as it was already promoted to main [14:35] but essentially the official way of Jon's oxidizer [14:35] It's rather minimal, primarily shipping symlinks [14:35] yes, that is what I see too [14:35] I didn't realize it was in main before [14:36] but that should most likely make it a fast path [14:36] being the only case to share, anyone volunteering? [14:37] *crickets* - ok so it is me I guess [14:37] #topic Incomplete bugs / questions [14:37] Mission: Identify required actions and spread the load among the teams [14:37] #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir [14:38] two recent cases [14:38] https://bugs.launchpad.net/ubuntu/+source/roman-numerals/+bug/2110098 [14:38] -ubottu:#ubuntu-meeting- Launchpad bug 2110098 in roman-numerals (Ubuntu) "Component mismatch due to the new roman-numerals dependency" [Undecided, Incomplete] [14:38] seems the path was not to do a MIR but to drop the dependency [14:38] pushkarnk: is that right? [14:38] That seems resolved, right pushkarnk ? We could mark roman-numerals as "Invalid" [14:39] if so I tihnk we can unsubscribe [14:39] Yes right cpaelzer [14:39] thanks, fone [14:39] done even [14:39] and [14:39] https://bugs.launchpad.net/ubuntu/+source/linuxptp/+bug/2071717 [14:39] -ubottu:#ubuntu-meeting- Launchpad bug 2071717 in linuxptp (Ubuntu) "[MIR] linuxptp" [Undecided, Incomplete] [14:39] which is an info about soon resolving incompleteness [14:39] good [14:40] yay apparmor profiles [14:40] as it is meant to be [14:40] #topic Process/Documentation improvements [14:40] Mission: Review pending process/documentation pull-requests or issues [14:40] #link https://github.com/canonical/ubuntu-mir/pulls [14:40] #link https://github.com/canonical/ubuntu-mir/issues [14:41] nothing really new except one [14:41] which is entertaining [14:41] https://github.com/canonical/ubuntu-mir/issues/86 [14:41] -ubottu:#ubuntu-meeting- Issue 86 in canonical/ubuntu-mir "not possible to link rules in the MIR text" [Open] [14:41] she's right, too [14:41] I think, once we are on the new place of ubuntu project docs this could be done [14:42] we then will have individual pages for the templates due to the diataxis split [14:42] it'd be worth keeping in mind that anchor tags are the most wonderful things ever when shoving it into the new ubuntu docs thingy [14:42] which means either we can make it the actual content and have anchors - or if that isn't doable at least we could enumerate the rules in the template [14:42] and then allow humans to refer to page + index [14:42] I discussed that with her at the sprint and both options seemed fine [14:43] I also love the comment to our bot telling to attend IRC meetings :-) [14:43] -1 on enumeration, those change; at least the horrible "search for this text" is much less likely to be changed [14:43] true, enumeration is only a fallback in my mind if all else fails [14:43] but it needs to be easily copy-able which I'm not sure if it goes well with putting anchors in [14:44] hmm. good point. [14:44] ok for now [14:44] I answered on the issue [14:45] #topic MIR related Security Review Queue [14:45] Mission: Check on progress, do deadlines seem doable? [14:45] Some clients can only work with one, some with the other escaping - the URLs point to the same place. [14:45] #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir&orderby=-date_last_updated&start=0 [14:45] #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=[MIR]&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir&orderby=-date_last_updated&start=0 [14:45] Internal link [14:45] - ensure your teams items are prioritized among each other as you'd expect [14:45] - ensure community requests do not get stomped by teams calling for favors too much [14:45] #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 [14:45] if things continue to come slowly and you can contine progress ... it almost feels you can clear the queue sarnold ! [14:45] rust-hwlib was done, I think you can set that complete [14:45] it has some detours which will make it contian less [14:46] rust-hwlib is still pending security review IIRC [14:46] but the security review was done, or was that for hte "re-review now that the former is fixed" [14:46] oh can we? I thought rodrigo said that it still needed some reviews, and he'll be away for two weeks, so he was offering it around [14:46] it had a brief check-up done. Needs a full re-review [14:46] got it, then all in the right state [14:46] with the reviewer being on vacation, currently. [14:46] anything else here? [14:46] I shall also be on vacation for two weeks Real Soon Now [14:47] so our chance to zero the queue seems thin :( I really liked that idea [14:47] let me have hope :-P [14:47] :) [14:47] but TBH enjoy the time off [14:47] ty :) [14:47] there will be more for you when you come back, I'm sure :-) [14:47] yes [14:47] let us go on here then [14:47] #topic Any other business? [14:47] Hi, I like to bring up Dracut (https://bugs.launchpad.net/ubuntu/+source/dracut/+bug/2031304) We want to make it the default this cycle. [14:47] -ubottu:#ubuntu-meeting- Launchpad bug 2031304 in dracut (Ubuntu) "[MIR] dracut" [Undecided, Fix Committed] [14:48] hi bdrung, I've heard about it - any particular special challenges? [14:48] reading ... [14:48] Dracut was reviewed for dracut-install and partially (?) for the whole Dracut. [14:49] some checks are all of the source by concept, but things like dependencies would only have considered dracut-install indeed [14:49] it looks like several "Later TODOs:" were added before moving to dracut more generally [14:49] so you are asking for a re-review with ?all? or another subset? [14:50] which of these later todos have been todone? [14:50] yep, later todo are #3-#6 [14:50] Yes, a re-review with ?all? would be nice (to be on the safe side). [14:51] dracut-cpio was not built (my personal goal is to use 3cpio soon[TM]) [14:51] can you give the answers if (or when and how) #3-#6 have been addressed on the bug [14:51] lol 3cpio [14:51] we will look for a volunteer here now to re-review ... [14:51] joalif: just had one, pushkarnk would you be open to have a look [14:52] since it was reviewed before this would mostly be for any recent oddity and dependencies [14:52] I can take a look [14:52] thanks [14:52] the dependencies are fixed (#6) [14:53] I set the state back and assigne pushkarnk [14:53] thanks [14:53] cpaelzer: ack [14:53] bdrung: that sounds good, if all are good just report them on the bug - but if one is like "hell now we won't do ..." then speak up here for discussion [14:54] one topic I haven't looked into is the netplan interaction [14:54] while you are thinking to answer that - I still need access to the ubuntu social photo (or be told where I missed the ping) [14:55] ok, give it a look and answer on the case then once you had a chance [14:55] cpaelzer, I pasted the ubuntu social photos in the frankfurt MM channel [14:55] ah there, thanks will look for it ... [14:56] I think we need to rush to the end of the meeting, but I wanted to thank bdrung - bringing it up early and then asking for re-review when extending is so nice and so how it should be. Thanks! [14:56] bdrung: We don't have Netplan in initrd IIRC. I remember ogayot investigating that situation. Also, there a community project: https://github.com/danielkza/dracut-netplan [14:57] anoth aob topic, FYI I made pushkarnk and myles team members on LP to allow ACLs to be based on it. As discussed in the sprint ,the actual learning is shadow into then autonomously doing reviews. [14:57] ack [14:57] slyon, may I ask you to look into the dracut/netplan and comment on the MIR? [14:57] ack [14:57] ack cpaelzer, thanks! [14:58] bdrung: yes, I can put my thoughts there! [14:58] cpaelzer, suggestions for future MIR meeting: Add one topic at the beginning of the meeting to allow outsider to push topics to the agenda. [14:58] thanks slyon [14:58] that is a good idea [14:59] we might - once we know - pull them forward or anything else [14:59] yes. it even matches common practice [14:59] do you feel like posting a PR for it? [14:59] or more like raising it here and let it be our task? [14:59] +1 for an external agenda item :) [14:59] next meeting is rushing me ... I need to count out [14:59] cpaelzer, is the meeting agenda in some git? [14:59] yes [14:59] https://github.com/canonical/ubuntu-mir#mir-team-weekly-status-meeting [15:00] counting .... and thanking you all [15:00] 4242 [15:00] 256 [15:00] 5 [15:00] #endmeeting [15:00] Meeting ended at 15:00:23 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2025/ubuntu-meeting.2025-05-20-14.32.moin.txt [15:00] I prefer that you change the agenda and I am happy to review the PR [15:00] thanks cpaelzer, all :) [15:00] thanks cpaelzer, all! [15:02] thanks cpaelzer, all :) [15:02] bdrung, cpaelzer https://github.com/canonical/ubuntu-mir/pull/87 [15:02] -ubottu:#ubuntu-meeting- Pull 87 in canonical/ubuntu-mir "Update README.md -- add meeting item for community agenda items" [Open] [19:00] o/ [19:00] hey [19:00] o/ [19:01] hello [19:01] teward: around-p? [19:02] I'm checking irclogs, did the 04-22 meeting happen or not? (I was on holidays and forgot to check the logs after) [19:02] no [19:02] We should start anyway [19:03] so we've missed two i think, one on 04-22, one during roadmap sprint [19:03] seb128 is down to chair I think? [19:03] yes [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] ACTION: 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] ACTION: 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] ACTION: TB to vote on the proposal at the next meeting [19:19] ACTION: 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] ACTION: mwhudson to remove the TB from ~launchpad-buildd-admins [19:25] ACTION: 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] ACTION: 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] 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] 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] 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] ACTION: 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] ACTION: teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC [19:34] ACTION: 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] ACTION: teward to write up a proposal for how the move away from the wiki will work [19:35] ACTION: 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] ACTION: 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]