20:01 <vorlon> #startmeeting
20:01 <meetingology> Meeting started at 20:01:50 UTC.  The chair is vorlon.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
20:01 <meetingology> Available commands: action, commands, idea, info, link, nick
20:01 <vorlon> [topic] Apologies
20:02 <vorlon> sil2100 in real time let us know he won't be attending today
20:02 <rbasak> 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 <vorlon> and it looks like we have everyone else here?
20:03 <vorlon> #topic Action review
20:03 <vorlon> 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 <rbasak> 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 <amurray> 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 <seb128> 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 <vorlon> seb128: thanks
20:05 <seb128> and we had 4 +1 votes so I think that's approved
20:05 <vorlon> agreed
20:05 <vorlon> mine is also carry-over
20:05 <vorlon> seb128: do you want to send a follow-up email to confirm this is approved?
20:05 <vorlon> (amurray had an action to do so for UbuntuKylin)
20:06 <amurray> yeah not sure how I missed that but will get to it later today
20:06 <seb128> vorlon, yes, I will send the budgie email
20:07 <vorlon> #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 <vorlon> #topic Scan the mailing list archive for anything we missed (standing item)
20:07 <vorlon> the various vote threads are accounted for, I think
20:07 <vorlon> two other threads on there we should probably touch base on
20:08 <vorlon> first is "VirtualBox Postmortem"
20:08 <vorlon> tsimonq2 let me know he wasn't available to attend this meeting today
20:08 <arraybolt3> I'm here in his absence.
20:08 <arraybolt3> (I did a bunch of the VirtualBox testing to solve the bug that email is related to.)
20:09 <vorlon> 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 <vorlon> (which would be seb128 or amurray rather than rbasak or myself)
20:10 <rbasak> 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 <rbasak> 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 <seb128> 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 <vorlon> 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 <seb128> rbasak, vorlon, do you have any insight if the SRU team is working on a reply?
20:11 <amurray> 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 <amurray> 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 <vorlon> I'm not aware of a current SRU team decision about responding to the email
20:12 <rbasak> The SRU team haven't had an opportunity to discuss this yet really.
20:13 <rbasak> 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 <rbasak> 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 <seb128> is that going to happen before the next TB meeting then? if so maybe let's revisit next time?
20:14 <rbasak> 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 <vorlon> should happen this week I think?
20:14 <rbasak> Yes - on Thursday - assuming the other relevant people are able to attend.
20:14 <arraybolt3> February 2, the new VBox SRU should be ready to go out. Me and LoB already did all verificaiton.
20:15 <arraybolt3> So I can confirm this week.
20:15 <vorlon> yes, SRU team meeting Thursday
20:15 <arraybolt3> (assuming the SRU team does migrations from -proposed to -updates on Friday - I don't actually know if this is the case)
20:15 <rbasak> I'd like to be constructive here, but I'm finding that quite challenging.
20:15 <rbasak> A couple of things to note, if you're expecting the release to happen because you've marked verification-done...
20:16 <seb128> 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 <vorlon> 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 <vorlon> 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 <arraybolt3> 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 <rbasak> 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 <rbasak> by the SRU team
20:18 <arraybolt3> 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 <rbasak> 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 <vorlon> arraybolt3: telling the SRU team "you owe N an apology" is a pretty hard tone to get past.
20:19 <rbasak> In bug 2050891, currently the Test Plan says: "Install virtualbox, run VMs". That is not an acceptable test plan IMHO.
20:19 <arraybolt3> Valid, I just am saying, don't throw the baby out with the bathwater.
20:20 <rbasak> I believe this has all been raised before, and not addressed.
20:20 <rbasak> So from my perspective, were I asked to release it, the SRU is blocked.
20:20 <arraybolt3> rbasak: I think LocutusOfBorg simply put the test plan in the wrong spot.
20:20 <Eickmeyer> 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 <arraybolt3> It's right under "Where Problems Could Occur" under the "Some Guest OSes might fail to load" part.
20:21 <Eickmeyer> Literally broke his spirit. That's no way to treat a community member.
20:21 <arraybolt3> I can fix that right now if it's needed to unblock the SRU.
20:21 <rbasak> 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 <rbasak> Let's be constructive please.
20:23 <seb128> 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 <rbasak> 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 <seb128> if not why did people do IRC pings instead of following the process?
20:23 <rbasak> So let's try to figure out how to get to a place where they are met, rather than throw accusations around.
20:23 <Eickmeyer> seb128: tsimonq2 pinged xnox .
20:23 <seb128> xnox isn't an SRU team member
20:24 <seb128> and that wouldn't flag the SRU as not to promote on the SRU report
20:24 <seb128> anyway, I don't think we will resolve that tonight
20:24 <seb128> 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 <vorlon> 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 <rbasak> 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 <Eickmeyer> 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 <arraybolt3> I'm fairly certain there's an SRU team meeting in this channel every four weeks?
20:26 <arraybolt3> 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 <vorlon> 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 <Eickmeyer> vorlon: A community team though, with community governance? I reject the notion that an open source team should be behind closed doors.
20:27 <vorlon> expecting teams to not have private meetings for working through outstanding task lists is unhelpful
20:28 <vorlon> I categorically reject this framing
20:28 <Eickmeyer> I categorically disagree.
20:28 <rbasak> arraybolt3: it's in tsimonq2's email
20:28 <arraybolt3> 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 <arraybolt3> rbasak: thanks, I am blind then :P
20:29 <Eickmeyer> arraybolt3: However, an SRU team isn't a team that has to deal with private matters regarding individuals.
20:29 <rbasak> 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 <arraybolt3> our meetings aren't about those either yet.
20:30 <seb128> 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 <rbasak> Pragmatically, we get stuff done quicker when the involved people can speak to each other high bandwidth without excessive bureaucracy
20:30 <vorlon> 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 <rbasak> seb128: I'm not aware that anybody flagged virtualbox as being broken by the new kernel.
20:31 <rbasak> At least, not to the SRU team.
20:31 <rbasak> Another complication is that the kernel SRU process operates fairly independently
20:31 <seb128> vorlon, ack
20:33 <rbasak> Eickmeyer: private matters regarding individuals> I disagree. The complaints posted _are_ accusatory of the conduct of individuals.
20:34 <vorlon> independently of the rest of the SRU team, and also independently of the britney-triggered autopkgtests
20:34 <rbasak> 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 <Eickmeyer> 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 <rbasak> I think it is in scope, but I cannot explain why exactly without going into private matters.
20:36 <rbasak> I'd be happy to explain to the TB in private, or to the CC in private.
20:36 <rbasak> 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 <vorlon> 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 <vorlon> #link https://lists.ubuntu.com/archives/technical-board/2024-January/002862.html launchpad-buildd-admin team ownership
20:37 <rbasak> 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 <rbasak> already do that.
20:38 <rbasak> So +1 from me
20:38 <vorlon> wgrant had approached me privately about this earlier and I said I had no reservations but that it should be public
20:39 <vorlon> 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 <vorlon> and there's no reason for that to be the case
20:39 <vorlon> and if we need stuff as AAs we can work that out directly with launchpad instead
20:39 <vorlon> any objections?
20:39 <amurray> +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 <vorlon> well. given that this is true it would still only be Canonical employees able to *exercise* that acl
20:40 <vorlon> and afaik none of us do
20:40 <amurray> indeed
20:41 <vorlon> ok 3 +1, I'll just follow up to the mail to confirm that as a TB position, thanks
20:41 <amurray> thanks vorlon
20:41 <vorlon> #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 <vorlon> #topic Check up on community bugs and techboard bugs
20:42 <vorlon> #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard
20:42 <vorlon> zaroo boogs
20:42 <vorlon> #link https://bugs.launchpad.net/techboard
20:42 <vorlon> nothing new :/
20:42 <Eickmeyer> Uh, what about Kubuntu requalification?
20:43 <seb128> sorry, I was catching up with other channels, I'm +1 also for the launchpad-buildd-admin
20:43 <vorlon> and there are carry-over actions for the two open bugs there
20:43 <vorlon> seb128: thanks
20:43 <seb128> Eickmeyer, I was going to ask about that in the AOB
20:43 <Eickmeyer> seb128: Ah, thx
20:43 <seb128> it just arrived an hour ago
20:44 <vorlon> 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 <vorlon> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
20:44 <vorlon> I believe next should be sil2100 with amurray as backup
20:44 <amurray> ack
20:45 <vorlon> #agreed next chair: sil2100, backup: amurray
20:45 <meetingology> AGREED: next chair: sil2100, backup: amurray
20:45 <vorlon> #topic AOB
20:45 <vorlon> seb128:
20:45 <seb128> we missed https://lists.ubuntu.com/archives/technical-board/2024-January/002864.html in the list review
20:45 <arraybolt3> (not bringing it up right now, but I have a question related to Lubuntu LTS requalification at some point before AOB ends)
20:45 <seb128> we should have somone doing the review and call for a vote if it's ready
20:46 <arraybolt3> 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 <vorlon> arraybolt3: might speed things up, sure
20:47 <vorlon> to be clear, flavors don't need to feel any urgency about this process (there was one email apologizing for being late)
20:47 <vorlon> we have until April to make final decisions
20:47 <Eickmeyer> To be fair, that's only 2 months with lots of stuff to do in between.
20:48 <arraybolt3> 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 <ricktimmis> +1
20:48 <vorlon> anyone on the TB want to volunteer to drive Kubuntu qual?
20:49 <amurray> I can take it
20:49 <vorlon> #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 <seb128> amurray, thanks!
20:49 <vorlon> amurray: thank
20:49 <vorlon> s
20:49 <arraybolt3> a single thank is good enough *ducks*
20:50 <ricktimmis> Happy to be point of contact for Kubuntu
20:50 <vorlon> ricktimmis: apologies, but I have no idea who you are that you are volunteering?
20:50 <arraybolt3> He is a Kubuntu Council member
20:51 <arraybolt3> https://launchpad.net/~kubuntu-council/+members#active
20:51 <vorlon> https://launchpad.net/~kubuntu-council/+members gotcha
20:51 <arraybolt3> (them and Scarlett are the contacts)
20:51 <vorlon> well anyway, Kubuntu folks should among them decide who it's going to be and post to the list please
20:51 <vorlon> ricktimmis: nice to meet you (after you've been on the Kubuntu Council for 6 years ;)
20:51 <arraybolt3> 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 <amurray> yes please, that way I know who to reply to since Scarlett didn't CC anyone else
20:52 <Eickmeyer> ricktimmis: You know me, so if you need help, you know who to find as well.
20:52 <vorlon> any other AOB?
20:52 <arraybolt3> o/
20:53 <rbasak> o/
20:53 <arraybolt3> is there anything else that needs done for Lubuntu's LTS requalification?
20:53 <arraybolt3> (that was me raising my hand)
20:53 <ricktimmis> Thx
20:53 <arraybolt3> (sorry, looked like a wave goodbye)
20:53 <arraybolt3> I don't know if it's been officially ratified yet, and this was something Simon wanted to bring up.
20:54 <vorlon> thanks for checking
20:55 <vorlon> 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 <rbasak> It wasn't threaded
20:55 <arraybolt3> sec, I'll dig it up
20:55 <vorlon> rbasak: yah but I don't see it at all?
20:55 <rbasak> "Updating Lubuntu's Release Management Delegation" dated Tue, 9 Jan 2024 16:06:05 +0000
20:55 <rbasak> Oh - it's not in the archive?
20:56 <arraybolt3> I'm seeing it as my reply to Lubuntu LTS Requalificatoin: 24.04 Noble Numbat
20:56 <vorlon> rbasak: *that* email was before my question, where the answer referenced that other email
20:56 <rbasak> https://lists.ubuntu.com/archives/technical-board/2024-January/002851.html is what I thought we're talking about
20:56 <arraybolt3> I definitely sent it to the list
20:56 <vorlon> so anyway uh list archive maybe broken
20:56 <vorlon> but I have it in my local mail archive
20:56 <rbasak> Oh, I see.
20:56 <rbasak> I didn't receive that email in that case
20:56 <vorlon> so I'll take the action to follow up and confirm Lubuntu status (I think we have enough +1s and no objections)
20:57 <rbasak> Oh wait
20:57 <rbasak> I did get it to ubuntu-release@
20:57 <arraybolt3> weird, yeah it looks like the archive just swallowed a bunch of stuff.
20:57 <vorlon> ahhhh
20:57 <arraybolt3> My name isn't anywhere on there.
20:57 <rbasak> https://lists.ubuntu.com/archives/ubuntu-release/2024-January/005891.html and onwards?
20:57 <vorlon> arraybolt3: well yes, the email I find from you is To: ubuntu-release@lists.ubuntu.com, Simon Quigley <tsimonq2@lubuntu.me>
20:57 <arraybolt3> ah, yep, that's it
20:57 <rbasak> technical-board@ wasn't included from then onwards
20:58 <arraybolt3> oh
20:58 <rbasak> (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 <vorlon> you even suckered a member of the TB to posting their +1 only to ubuntu-release
20:58 <arraybolt3> hahahahaha
20:58 <vorlon> I've just bounced a bunch of mails to the list from my mailbox, let's see if that works
20:58 <arraybolt3> Thunderbird is hard
20:58 <Eickmeyer> 🤣
20:59 <vorlon> #action vorlon to confirm ratification of Lubuntu LTS
20:59 * meetingology vorlon to confirm ratification of Lubuntu LTS
20:59 <vorlon> we're at time and I think that's everything?
21:00 <arraybolt3> nothing else from me
21:00 <amurray> nothing from me
21:00 <rbasak> As we're out of time I'll add an item to the agenda for our next meeting instead
21:00 <seb128> rbasak raised his hand earlier?
21:00 <seb128> rbasak, ack
21:01 <vorlon> #endmeeting