== Meeting information == * #ubuntu-meeting meeting, started by vorlon, 30 Jan at 20:01 — 21:01 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-01-30-20.01.log.html == Meeting summary == === Apologies === Discussion started by vorlon at 20:01. === Action review === Discussion started by vorlon at 20:03. * ''ACTION:'' seb128 to send confirmation of successful LTS status for UbuntuBudgie 24.04 (vorlon, 20:07) === Scan the mailing list archive for anything we missed (standing item) === Discussion started by vorlon at 20:07. * ''LINK:'' https://wiki.ubuntu.com/StableReleaseUpdates#virtualbox is false. Contrary to what that says, I don't consider anything pre-approved by the SRU. I've mentioned this on IRC to LocutusOfBorg before. (rbasak, 20:17) * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2024-January/002862.html launchpad-buildd-admin team ownership (vorlon, 20:37) * ''ACTION:'' vorlon to confirm TB agreement to launchpad-buildd-admins ownership change (vorlon, 20:41) === Check up on community bugs and techboard bugs === Discussion started by vorlon at 20:41. * ''LINK:'' https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard (vorlon, 20:42) * ''LINK:'' https://bugs.launchpad.net/techboard (vorlon, 20:42) === Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) === Discussion started by vorlon at 20:44. * ''AGREED:'' next chair: sil2100, backup: amurray (vorlon, 20:45) === AOB === Discussion started by vorlon at 20:45. * ''ACTION:'' amurray to follow up with Kubuntu on 24.04 LTS request (vorlon, 20:49) * ''LINK:'' https://launchpad.net/~kubuntu-council/+members#active (arraybolt3, 20:51) * ''LINK:'' https://launchpad.net/~kubuntu-council/+members gotcha (vorlon, 20:51) * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2024-January/002851.html is what I thought we're talking about (rbasak, 20:56) * ''LINK:'' https://lists.ubuntu.com/archives/ubuntu-release/2024-January/005891.html and onwards? (rbasak, 20:57) * ''ACTION:'' vorlon to confirm ratification of Lubuntu LTS (vorlon, 20:59) == Action items, by person == * amurray * amurray to follow up with Kubuntu on 24.04 LTS request * seb128 * seb128 to send confirmation of successful LTS status for UbuntuBudgie 24.04 * vorlon * vorlon to confirm TB agreement to launchpad-buildd-admins ownership change * vorlon to confirm ratification of Lubuntu LTS == People present (lines said) == * vorlon (82) * rbasak (49) * arraybolt3 (40) * seb128 (25) * Eickmeyer (14) * amurray (11) * meetingology (7) * ricktimmis (3) == Full log == 20:01 #startmeeting 20:01 Meeting started at 20:01:50 UTC. The chair is vorlon. Information about MeetBot at https://wiki.ubuntu.com/meetingology 20:01 Available commands: action, commands, idea, info, link, nick 20:01 [topic] Apologies 20:02 sil2100 in real time let us know he won't be attending today 20:02 The agenda looks quiet today, but I think there are some flavour LTS qualifications outstanding from the ML, and also I'd like to discuss my "onsensus on question of test plans for third party apps" action item if we have time. 20:02 and it looks like we have everyone else here? 20:03 #topic Action review 20:03 there are a lot of actions listed; rather than going point-by-point, can I just ask if anyone has updates, and assume the rest are carry-over? https://wiki.ubuntu.com/TechnicalBoardAgenda 20:04 All mine are to carry over please. Though as above I've been looking at one, might as well carry it over until discussed since it's unlikely to be resolved completely today. 20:04 sounds good to me (mine are all carry-over) 20:04 * seb128 seb128 to follow-up with ubuntu cinnamon on 24.04 request -> https://lists.ubuntu.com/archives/technical-board/2024-January/002853.html 20:04 no reply from them though 20:04 * seb128 seb128 to follow-up with ubuntu budgie on 24.04 request -> https://lists.ubuntu.com/archives/technical-board/2024-January/002855.html 20:05 seb128: thanks 20:05 and we had 4 +1 votes so I think that's approved 20:05 agreed 20:05 mine is also carry-over 20:05 seb128: do you want to send a follow-up email to confirm this is approved? 20:05 (amurray had an action to do so for UbuntuKylin) 20:06 yeah not sure how I missed that but will get to it later today 20:06 vorlon, yes, I will send the budgie email 20:07 #action seb128 to send confirmation of successful LTS status for UbuntuBudgie 24.04 20:07 * meetingology seb128 to send confirmation of successful LTS status for UbuntuBudgie 24.04 20:07 #topic Scan the mailing list archive for anything we missed (standing item) 20:07 the various vote threads are accounted for, I think 20:07 two other threads on there we should probably touch base on 20:08 first is "VirtualBox Postmortem" 20:08 tsimonq2 let me know he wasn't available to attend this meeting today 20:08 I'm here in his absence. 20:08 (I did a bunch of the VirtualBox testing to solve the bug that email is related to.) 20:09 I have lots of thoughts in regards to that email, but perhaps someone who's not wearing dual TB + SRU hats wants to comment first 20:09 (which would be seb128 or amurray rather than rbasak or myself) 20:10 I do wear both hats, but my usual response in these cases is to ask for the responsible team to respond in the first instance. 20:10 In other words, even when TB escalation is appropriate, the TB should seek to get input from both sides - from both the complainant(s) and the responsible teams. In this case that'd be the SRU team, rather than non-SRU team members. 20:11 right, I'm unsure if that's a topic for the TB at this point, I would like at least to see a reply from the SRU team first 20:11 well I'm going to say that the reason I haven't responded to this email at all yet is that I found it to be an entirely unconstructive and anti-collaborative approach to the question 20:11 rbasak, vorlon, do you have any insight if the SRU team is working on a reply? 20:11 from my point of view, whilst I can entirely understand the frustrations expressed in the email, I also can sympathise with the SRU team et al - due to the distributed / silo'd nature of Ubuntu development this kind of thing feels sometimes inevitable even when we try hard to coordinate to avoid such situations 20:12 so unless a response from the SRU team highlights any particular problems on their side, I am not sure there is much for the TB to do at this time 20:12 I'm not aware of a current SRU team decision about responding to the email 20:12 The SRU team haven't had an opportunity to discuss this yet really. 20:13 The relevant people to discuss this are in a late-ish timezone, and we usually chat every four weeks, and that hasn't come up yet. 20:14 I don't mind going into more details now, on behalf of the SRU team, and while vorlon's also here. But maybe that's not really appropriate right now (or do others think otherwise?) 20:14 is that going to happen before the next TB meeting then? if so maybe let's revisit next time? 20:14 It might be if we were in a rush, but I have noticed SRU activity on this package, so is there still a rush? 20:14 should happen this week I think? 20:14 Yes - on Thursday - assuming the other relevant people are able to attend. 20:14 February 2, the new VBox SRU should be ready to go out. Me and LoB already did all verificaiton. 20:15 So I can confirm this week. 20:15 yes, SRU team meeting Thursday 20:15 (assuming the SRU team does migrations from -proposed to -updates on Friday - I don't actually know if this is the case) 20:15 I'd like to be constructive here, but I'm finding that quite challenging. 20:15 A couple of things to note, if you're expecting the release to happen because you've marked verification-done... 20:16 that's a long email with a lot of details, but to me it seems the SRU team should maybe add to their process to check if a kernel update breaks virtualbox 20:17 yes, a "post mortem" which assumes itself to be in possession of all of the facts without consulting > half the people involved, and drawing conclusions and assigning blame, is not a springboard for a constructive discussion 20:17 seb128: that's the thing, I haven't had time to dig into this, but kernel SRUs are supposed to check the results of all dkms package builds 20:17 I think with the virtualbox breakage bug, the issue was that the update was never accepted into proposed in the first place. There was nothing any other team could have done. 20:17 https://wiki.ubuntu.com/StableReleaseUpdates#virtualbox is false. Contrary to what that says, I don't consider anything pre-approved by the SRU. I've mentioned this on IRC to LocutusOfBorg before. 20:17 by the SRU team 20:18 I didn't read Simon's email as attempting to be a be-all-end-all postmortem, I thought it was intended to start discussion, laying out everything Simon knew already. His tone is rather negative, but I think he was trying to be constructive and that he had some good points if you read past the tone. 20:19 From what I consider to be the draft at https://wiki.ubuntu.com/VirtualboxUpdates, it's not clear to me what precisely is committed to being verified, and even if it were, that hasn't been agreed by the SRU team. Therefore, there isn't a standard for me to confirm against that appopriate verification has been performed. 20:19 arraybolt3: telling the SRU team "you owe N an apology" is a pretty hard tone to get past. 20:19 In bug 2050891, currently the Test Plan says: "Install virtualbox, run VMs". That is not an acceptable test plan IMHO. 20:19 Valid, I just am saying, don't throw the baby out with the bathwater. 20:20 I believe this has all been raised before, and not addressed. 20:20 So from my perspective, were I asked to release it, the SRU is blocked. 20:20 rbasak: I think LocutusOfBorg simply put the test plan in the wrong spot. 20:20 To be fair, LoB told people in private chats that he was feeling ignored and got tired of pinging in #ubuntu-release since October that an SRU of virtualbox was ready for review. So, this was not a failure on his part. 20:20 It's right under "Where Problems Could Occur" under the "Some Guest OSes might fail to load" part. 20:21 Literally broke his spirit. That's no way to treat a community member. 20:21 I can fix that right now if it's needed to unblock the SRU. 20:21 My frustration is that we iterated enough times already and it's still not acceptable to me. When I've been asked, I've tried to be helpful. I believe that conversation has already been linked to. 20:22 Let's be constructive please. 20:23 I didn't found the detail by reading through the email again, but did anyone attempted to block promotion to updates of the kernel by flagging that it created a regression? 20:23 I hope it's quite clear that currently expectations are far from being met, and that this is the root cause of the issue. 20:23 if not why did people do IRC pings instead of following the process? 20:23 So let's try to figure out how to get to a place where they are met, rather than throw accusations around. 20:23 seb128: tsimonq2 pinged xnox . 20:23 xnox isn't an SRU team member 20:24 and that wouldn't flag the SRU as not to promote on the SRU report 20:24 anyway, I don't think we will resolve that tonight 20:24 I would suggest we wait for the SRU team meeting this week and to see if there is an outcome of that discussion 20:25 true, but I think it's useful to have this frank discussion about some of the issues here, that as I mentioned was a bit blocked on the lists because long-form emails are something of a barrier 20:25 From my perspective, if someone says something is ready for review, I ask for substantial changes, they don't fix what I requested and then say it's ready for review again, so I ask for substantial changes, ad infinitum, at what point is it no longer reasonable to claim that I'm treating the uploader badly? 20:25 Another point: The SRU team meets *every four weeks?* Is this a time constraint issue, because, as someone with a leadership degree, this is not how teams are run under any circumstance. Furthermore, does the SRU team meet *behind closed doors*? That seems pretty suspicious to me. 20:26 I'm fairly certain there's an SRU team meeting in this channel every four weeks? 20:26 rbasak: "I believe that conversation has already been linked to." I may be blind, but I don't see the link. (I'd just like to look over it so I can get a better understanding.) 20:26 I reject the characterization of this as "suspicious". The SRU team is not a "leadership" team, it is a functional team with work to do and the meetings are internal to the team for getting things done 20:27 vorlon: A community team though, with community governance? I reject the notion that an open source team should be behind closed doors. 20:27 expecting teams to not have private meetings for working through outstanding task lists is unhelpful 20:28 I categorically reject this framing 20:28 I categorically disagree. 20:28 arraybolt3: it's in tsimonq2's email 20:28 I'll have to agree with vorlon. We have a private Matrix Operators meeting every week in order to discuss difficult technical and management topics, we're an open-source and community-related team, and this is what is working best for us so far. 20:28 rbasak: thanks, I am blind then :P 20:29 arraybolt3: However, an SRU team isn't a team that has to deal with private matters regarding individuals. 20:29 arraybolt3: well, it is difficult. That's the issue with these threads that get longer and longer - they take expontentially more time to follow. 20:29 our meetings aren't about those either yet. 20:30 rbasak, what I don't understand is that from that number of pings and the review of the virtualbox SRU how did we end up in a situation where nobody from the SRU team though we had a problem that needed to be resolved in some way before promoting the new kernel? 20:30 Pragmatically, we get stuff done quicker when the involved people can speak to each other high bandwidth without excessive bureaucracy 20:30 seb128: those kinds of technical details I think are something best worked through by the SRU team as we sort out responding to the email 20:30 seb128: I'm not aware that anybody flagged virtualbox as being broken by the new kernel. 20:31 At least, not to the SRU team. 20:31 Another complication is that the kernel SRU process operates fairly independently 20:31 vorlon, ack 20:33 Eickmeyer: private matters regarding individuals> I disagree. The complaints posted _are_ accusatory of the conduct of individuals. 20:34 independently of the rest of the SRU team, and also independently of the britney-triggered autopkgtests 20:34 There are various aspects of this matter that I am deliberately not going into here because it is inappropriate to discuss them publicly. 20:35 rbasak: Why is the SRU team discussing complaints of the conduct of individuals? That seems out of scope? 20:35 * Eickmeyer is confused 20:35 I think it is in scope, but I cannot explain why exactly without going into private matters. 20:36 I'd be happy to explain to the TB in private, or to the CC in private. 20:36 But an escalation to the CC at this stage I think would be counterproductive. We need to stop being accusatory and try and resolve this constructively. 20:37 ok it's clear that the ball is in the SRU team's court for responding to the email, and I think we've exhausted any useful informal discussion here on the topic. Moving on 20:37 #link https://lists.ubuntu.com/archives/technical-board/2024-January/002862.html launchpad-buildd-admin team ownership 20:37 On that topic, Ubuntu's infrastructure provision arrangements from Canonical pre-date my involvement, but there's plenty of stuff that we rely very heavily on Canonical IS for, and I don't see any reason why this case needs to be an exception. So following the existing pattern, it makes sense to me to delegate management of this stuff to Canonical, just like various other infrastructure where we 20:37 already do that. 20:38 So +1 from me 20:38 wgrant had approached me privately about this earlier and I said I had no reservations but that it should be public 20:39 of anyone likely to be accidentally exercising this privilege, it would be those members of the Archive Admin team that *happen* to also be on the TB (me, sil2100, seb128) 20:39 and there's no reason for that to be the case 20:39 and if we need stuff as AAs we can work that out directly with launchpad instead 20:39 any objections? 20:39 +1 from me too (although I can't help but notice that since all current TB members are Canonical employees I wonder if there is a perceived conflict of interest in being asked about this) 20:40 well. given that this is true it would still only be Canonical employees able to *exercise* that acl 20:40 and afaik none of us do 20:40 indeed 20:41 ok 3 +1, I'll just follow up to the mail to confirm that as a TB position, thanks 20:41 thanks vorlon 20:41 #action vorlon to confirm TB agreement to launchpad-buildd-admins ownership change 20:41 * meetingology vorlon to confirm TB agreement to launchpad-buildd-admins ownership change 20:41 #topic Check up on community bugs and techboard bugs 20:42 #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard 20:42 zaroo boogs 20:42 #link https://bugs.launchpad.net/techboard 20:42 nothing new :/ 20:42 Uh, what about Kubuntu requalification? 20:43 sorry, I was catching up with other channels, I'm +1 also for the launchpad-buildd-admin 20:43 and there are carry-over actions for the two open bugs there 20:43 seb128: thanks 20:43 Eickmeyer, I was going to ask about that in the AOB 20:43 seb128: Ah, thx 20:43 it just arrived an hour ago 20:44 ok sorry I was assuming that the flavor qual stuff as a whole was in hand and failed to consider that the new mail should have a driver assigned to it 20:44 #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) 20:44 I believe next should be sil2100 with amurray as backup 20:44 ack 20:45 #agreed next chair: sil2100, backup: amurray 20:45 AGREED: next chair: sil2100, backup: amurray 20:45 #topic AOB 20:45 seb128: 20:45 we missed https://lists.ubuntu.com/archives/technical-board/2024-January/002864.html in the list review 20:45 (not bringing it up right now, but I have a question related to Lubuntu LTS requalification at some point before AOB ends) 20:45 we should have somone doing the review and call for a vote if it's ready 20:46 w.r.t. the Kubuntu LTS requalification, I see that Scarlett didn't list any official contacts. This was a hang-up for Lubuntu, and I know who the contacts are. Would it be helpful for me to reply to that email with that info so that someone from the Kubuntu Council can +1 it? 20:47 arraybolt3: might speed things up, sure 20:47 to be clear, flavors don't need to feel any urgency about this process (there was one email apologizing for being late) 20:47 we have until April to make final decisions 20:47 To be fair, that's only 2 months with lots of stuff to do in between. 20:48 still, good to know that we aren't already too late (I was a bit worried with how long Lubuntu was taking, so this is good new info for me to have). 20:48 +1 20:48 anyone on the TB want to volunteer to drive Kubuntu qual? 20:49 I can take it 20:49 #action amurray to follow up with Kubuntu on 24.04 LTS request 20:49 * meetingology amurray to follow up with Kubuntu on 24.04 LTS request 20:49 amurray, thanks! 20:49 amurray: thank 20:49 s 20:49 a single thank is good enough *ducks* 20:50 Happy to be point of contact for Kubuntu 20:50 ricktimmis: apologies, but I have no idea who you are that you are volunteering? 20:50 He is a Kubuntu Council member 20:51 https://launchpad.net/~kubuntu-council/+members#active 20:51 https://launchpad.net/~kubuntu-council/+members gotcha 20:51 (them and Scarlett are the contacts) 20:51 well anyway, Kubuntu folks should among them decide who it's going to be and post to the list please 20:51 ricktimmis: nice to meet you (after you've been on the Kubuntu Council for 6 years ;) 20:51 ricktimmis: it sounds like you're better equipped to post that info, so I'll leave that alone so I don't mess anything up :P 20:52 yes please, that way I know who to reply to since Scarlett didn't CC anyone else 20:52 ricktimmis: You know me, so if you need help, you know who to find as well. 20:52 any other AOB? 20:52 o/ 20:53 o/ 20:53 is there anything else that needs done for Lubuntu's LTS requalification? 20:53 (that was me raising my hand) 20:53 Thx 20:53 (sorry, looked like a wave goodbye) 20:53 I don't know if it's been officially ratified yet, and this was something Simon wanted to bring up. 20:54 thanks for checking 20:55 looking at the mailing list archive I find myself confused because I was pretty sure there was a reply to my question about the contacts on list but I don't see it there 20:55 It wasn't threaded 20:55 sec, I'll dig it up 20:55 rbasak: yah but I don't see it at all? 20:55 "Updating Lubuntu's Release Management Delegation" dated Tue, 9 Jan 2024 16:06:05 +0000 20:55 Oh - it's not in the archive? 20:56 I'm seeing it as my reply to Lubuntu LTS Requalificatoin: 24.04 Noble Numbat 20:56 rbasak: *that* email was before my question, where the answer referenced that other email 20:56 https://lists.ubuntu.com/archives/technical-board/2024-January/002851.html is what I thought we're talking about 20:56 I definitely sent it to the list 20:56 so anyway uh list archive maybe broken 20:56 but I have it in my local mail archive 20:56 Oh, I see. 20:56 I didn't receive that email in that case 20:56 so I'll take the action to follow up and confirm Lubuntu status (I think we have enough +1s and no objections) 20:57 Oh wait 20:57 I did get it to ubuntu-release@ 20:57 weird, yeah it looks like the archive just swallowed a bunch of stuff. 20:57 ahhhh 20:57 My name isn't anywhere on there. 20:57 https://lists.ubuntu.com/archives/ubuntu-release/2024-January/005891.html and onwards? 20:57 arraybolt3: well yes, the email I find from you is To: ubuntu-release@lists.ubuntu.com, Simon Quigley 20:57 ah, yep, that's it 20:57 technical-board@ wasn't included from then onwards 20:58 oh 20:58 (it was neither in To: nor Cc:) 20:58 * arraybolt3 missed we were hunting through the technical-board ML, I thought this was ubuntu-release :P 20:58 you even suckered a member of the TB to posting their +1 only to ubuntu-release 20:58 hahahahaha 20:58 I've just bounced a bunch of mails to the list from my mailbox, let's see if that works 20:58 Thunderbird is hard 20:58 🤣 20:59 #action vorlon to confirm ratification of Lubuntu LTS 20:59 * meetingology vorlon to confirm ratification of Lubuntu LTS 20:59 we're at time and I think that's everything? 21:00 nothing else from me 21:00 nothing from me 21:00 As we're out of time I'll add an item to the agenda for our next meeting instead 21:00 rbasak raised his hand earlier? 21:00 rbasak, ack 21:01 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)